For years, unwritten knowledge was your best protection. What you knew but couldn't easily document was what made you hard to replace.

With AI it's the exact opposite. For it to work well, you have to make explicit what was previously intuitive. You have to write down how you think, what you prioritize, how you structure problems. This has made people with solid work methodologies automatically much more productive.

Because you're able to articulate your work methodology, you can make AI replicate it. This carries a risk: what's explicit is transferable.

If you work for clients and deliver those configurations, you didn't just deliver the project. You delivered your way of working, your methodology, and your judgment accumulated over years of practice.

The line is clearer than it seems

What goes into the project configuration:

• Stack conventions
• Domain rules
• Business-specific context

Everything that exists because it's that project. That belongs to the client and should stay with them.

What stays with you:

• What questions you ask before starting
• How you evaluate whether the result is good
• How you detect when AI is wrong
• How you orchestrate multiple tools to work together
• How you extract knowledge to build automations
• How much you research and stay up to date
• What patterns you identify in new tools to integrate them into your workflows

The first list describes the project. The second list describes you.

A client can keep the first one. The second is built over years of practice and it belongs to you — don't give it away.

Company-level collective knowledge

There's another category: collective knowledge at the company level.

At company level, there are configurations, internal tools and methodologies that multiply the effectiveness of the entire team. Those belong to the company and benefit everyone who works there.

The key is knowing how to distinguish what's personal, what's collective knowledge at your company level that you can share with your colleagues for everyone's benefit, and what's project-specific knowledge that can be delivered to your client.

They're like employees: a junior needs detailed instructions, a senior acts with little context. If you throw a junior into the jungle, don't complain later when they do what you didn't expect.

Multi-agent systems are teams

Multi-agent systems work like teams: they need clear roles, success criteria, mechanisms to escalate blockers, and an orchestrator that synchronizes them and keeps the focus on the overall objective.

They need leaders. The seat-warmers will be the next token-burners.

The difference between agent systems and human teams is that there are no meetings, no standups, and no waiting.

Can you imagine having to wait for the standup to use your next Claude Code session? Or waiting until Thursday's meeting with the client to give them the requirements? Or waiting two weeks to define what goes into the next sprint?

Agents don't wait. They receive instructions, execute, report back, and take on the next task. Like a newly hired employee at their dream company who gets paid well to work on an exciting project.

Leadership principles that transfer

If you're a good leader of humans, your agents will thank you. The same principles apply:

• Clear context: Agents need to understand why, not just what. The more context you provide, the better their decisions.
• Defined boundaries: What can they decide on their own? When should they escalate? Without this, agents either block on everything or go rogue.
• Success criteria: How do you know the output is good? If you can't define it for a human, you can't define it for an agent.
• Feedback loops: Agents need to know when they got it right and when they didn't. This is how you iterate on prompts and configurations.

The companies that will get the most out of agentic AI are the ones that already know how to lead well. The tool is new, but the skill is ancient.

It encompasses everything a person lives, feels, and perceives from the moment they join an organization until they leave: the culture, the leadership, the tools, the processes, the recognition, the communication, and the colleagues.

In some places it's treated as a priority. In others it's an afterthought. But what's absolutely clear is that in any organization, someone who's been there for a while knows perfectly well who produces results and who only produces noise.

You don't need a performance report or an evaluation. You can see it in who shows up when there's a hard problem, a compromised situation. Who delivers without anyone having to chase them. Who adds to the team and helps everyone improve.

The noise makers

Generally, the person who produces value and generates results is ignored by whoever only produces noise, because they see their position threatened — worried that others might compare and notice they're not contributing.

Curiously, one way these noise-makers protect themselves is by creating processes and bureaucracy that slow everyone down equally, making it harder to distinguish who actually delivers.

The exhaustion of the doers

The real exhaustion doesn't come from the workload. It comes from proposing improvements that never get implemented.

From flagging problems that get ignored until they explode — and then suddenly everything is urgent.

From having conversations that lead nowhere with people who ask a lot and listen very little.

That exhaustion doesn't appear overnight. It accumulates slowly, meeting after meeting, broken promise after broken promise, feedback thrown into the void, watching their proposals get ignored while being asked to solve problems generated by others' incompetence.

And not in their own way, but in the way of whoever manages them. The way that they've already seen fail before and will fail again, but that nobody questions because questioning makes uncomfortable whoever doesn't want to be questioned.

Nothing irritates high performers more than: "solve this problem that was created by not listening to you, and solve it my way — the way that never works."

When they stop trying

There comes a point when the people who add value stop proposing, stop identifying improvement opportunities, and stop investing energy in a system that doesn't give it back.

That's the most expensive moment for any organization — and it's almost always invisible until it's too late.

They evaluate their employees by what they know, not by what they're capable of producing with the tools they master.

They're reluctant to implement new technologies or new approaches because they have a dinosaur that someone created years ago and worked at the time. Or worse — they ask you to innovate but while carrying the dinosaur with you, using the dinosaur everywhere, and your goal is to make the dinosaur innovative.

They make you attend meetings to say what you did today, when it could be a message or email.

They make you sit in meetings to take notes, when summaries are auto-generated and you could use that time on something productive.

They expect immediate results without giving their teams space to explore, experiment, and learn the technology.

The "You're totally right" loop

Now AI has arrived and the pattern repeats. If your team hasn't learned how to use AI and give it correct instructions, it will help them 50% of the time. The other 50% they'll be in an infinite loop of "You're totally right," accepting suggestions blindly hoping that this time it works, until they completely lose control of what they're doing.

At that point, the one in control isn't that person — it's the AI. The only question is who's paying for the license and the tokens being burned.

What successful companies do differently

Meanwhile, the companies that actually succeed:

• Give their teams explicit time to explore without immediate deliverables
• Allow experimentation and failure
• Provide resources to iterate until they find what works
• Integrate everything gradually
• Train their people to use the technology correctly

The pattern always repeats

The companies that win long-term are the ones that invest in their teams' learning, not just in the technology.

This time will be no different.

Dedicate time to adopt all of this, give your people space to experiment and try without fear, and in a few months you'll see the tree starting to bear fruit.

Curiously, when problems appear (and they always do), you usually think: "I wish I had closed the deal with whoever was honest from the beginning."

This is what those of us who work in technology face constantly. In the end, it all comes down to integrity and trust.

You can show vision without deceiving

You don't need to create a fake demo to explain where you're going. You can use a Figma prototype with a well-explained flow to show the idea and the value.

Meanwhile, the development team takes care of what matters: building the foundations and a solid base.

A fake demo isn't just technical debt — it's trust debt with whoever sees it. You start a relationship with a client or investor based on something you know isn't true.

Being clear from the start

Personally, I prefer being clear from the beginning: explain the vision, the roadmap, where we are today, and where we're heading. If the other party values that transparency, you'll build something solid together.

And if they don't value it, you probably didn't want that client anyway. Because when things get complicated (and they always do), you'll wish you had closed with someone who valued honesty.

Being honest, having integrity, and being reliable will make your clients recommend you. In the long run, that's what will speak for you.

State management is an essential aspect of building web applications. In complex applications, state management can become challenging, and manual state management can lead to issues like race conditions, bugs, and other inconsistencies. XState is a JavaScript library that provides a solution to these challenges by allowing developers to model state in a declarative, composable, and testable way. In this article, we will explore how to use state machines in React JS applications with XState.

What is XState?

XState is a JavaScript library for creating state machines. It is a finite state machine library that makes it easy to create state machines that are composable, testable, and easy to reason about. XState provides a simple, declarative syntax for defining state machines that can be used in any JavaScript environment.

What are state machines?

State machines are a mathematical concept used to model systems that have a finite number of states and can transition between those states based on events. In the context of web development, state machines are used to model the behavior of the user interface in response to user interactions or system events.

How to use state machines in React with XState

To use state machines in React with XState, we need to follow these steps:

Define a state machine: The first step is to define a state machine using the XState library. A state machine is defined using a set of states, events, and transitions. For example, here's a simple state machine for a toggle button:

import { createMachine } from 'xstate'

const toggleMachine = createMachine({
  id: 'toggle',
  initial: 'off',
  states: {
    off: {
      on: { TOGGLE: 'on' },
    },
    on: {
      on: { TOGGLE: 'off' },
    },
  },
})

In this state machine, we define two states: off and on. The state machine starts in the off state. When the TOGGLE event is received, the state machine transitions to the other state.

Create a state machine instance: Once we have defined our state machine, we need to create an instance of it using the useMachine hook from the @xstate/react package. Here's an example:

import { useMachine } from '@xstate/react'
import { toggleMachine } from './toggleMachine'

function App() {
  const [state, send] = useMachine(toggleMachine)

  return (
    <div>
      <button onClick={() => send('TOGGLE')}>{state.value}</button>
    </div>
  )
}

In this example, we import our toggleMachine state machine and create an instance of it using the useMachine hook. The useMachine hook returns an array containing the current state and a send function that can be used to send events to the state machine.

Render the state machine: Finally, we need to render our state machine. We can do this by using the current state returned by the useMachine hook to render the appropriate UI. Here's an example:

import { useMachine } from '@xstate/react'
import { toggleMachine } from './toggleMachine'

function App() {
  const [state, send] = useMachine(toggleMachine)

  return (
    <div>
      <button onClick={() => send('TOGGLE')}>
        {state.value === 'off' ? 'Turn on' : 'Turn off'}
      </button>
    </div>
  )
}

Advantages of using state machines with XState

Using state machines with XState in React applications has several advantages:

• Declarative: XState provides a declarative syntax for defining state machines. This makes it easier to understand the behavior of the system and how it responds to events.

• Composable: State machines can be composed to create more complex state machines. This allows developers to break down complex systems into smaller, more manageable pieces.

• Testable: XState state machines can be tested in isolation, making it easier to write tests for complex systems.

• Scalable: As applications grow in complexity, XState state machines provide a way to manage state in a scalable and maintainable way.

Conclusion

XState is a powerful tool for managing state in React applications. By using state machines, developers can create composable, testable, and scalable state management solutions. XState provides a declarative syntax for defining state machines and the useMachine hook from the @xstate/react package makes it easy to use state machines in React applications.

Many times we find ourselves with code that is impossible to maintain, or that we do not know if changing it will modify some behavior we do not want because it is not tested, or even we ourselves create code to complete a task without caring whether it is tested, scalable and maintainable since our mission is to deliver a feature.

As developers, we should be professionals. When code is difficult to test, it is a sign that it is tightly coupled to the rest of the application and likely needs to be refactored. But what does it mean to refactor?

The definition of refactoring is to make changes to the internal structure of software to make it easier to understand and cheaper to modify without changing its behavior.

To achieve this last premise, we need a reliable and measurable way to know whether the behavior has changed or not. We can do this through unit tests, integration tests, and end-to-end tests.

At this point, we know two things:

• What refactoring is
• To refactor, we need to test our code

There is a "boy scout" principle in software development that says when you encounter code, try to leave it better than you found it. Obviously, we cannot spend the day refactoring every file we open, but we can improve the files we have to work on to implement a new feature or fix a bug.

First crawl, then walk, then run

When we have to add a new feature to our code but it is not structured correctly, we should first refactor it so that the feature is easy to implement, and then add the feature. This should be done in separate processes, that is, first refactor (commit) and then add the feature (commit). This way, in a code review, it is much easier to explain the reason for the refactoring and explain the functionality without mixing one thing with the other.

We need to be aware that we are not refactoring when we change the code without having tests to verify that its behavior has not changed. We are only changing code, but not refactoring.

The best advice I can give you when you have a large and tightly coupled codebase is to start separating it little by little. Just like when a forensic officer finds a crime scene, we must start looking for evidence that tells us what is happening and allows us to gradually understand what is happening. Once we have evidence ("this piece of code does X"), we can extract it to an independent function and test it.

Use pure functions

A good tip here is to create pure functions, that is, given the same input, they always return the same output. This way, we can easily test it, and we will have taken a small step in our refactoring. Remember: mutability is the devil.

A good naming

Another good tip is to give a good name to our functions and variables. X, Y, Z, aux ...are not a good name. The code should tell what it does without going into its implementation.

The truth is that it is quite common to talk about all this but in practice nobody, or very few people do it. It is normal and understandable, many times we do not have all the time in the world to make a perfect code. In this case, I can give you three tips:

Learn TDD. If you test your code first, you will automatically have your code tested and documented. At the beginning the development will be slow, but little by little you will pick up speed until you start delivering high quality tested code. Your customers or your company will see that Pepito's code has very few bugs or in the case of having them, it is easy to detect where and fix them by having a good test coverage.

As you learn TDD, you can create your test after making a feature. It is best to follow the DRY (Don't repeat yourself) and KISS (Keep it stupid simple) principles. This way even if you can't test everything (for example, you don't have time to learn how to test a custom hook in React), most functions and utilities can be tested.

If you don't know how to test, as you learn how to test, add comments to your functions detailing how they should work and a TODO to replace that comment with a test or a series of tests to check (and document) their behavior.

References

As a final point to this blog entry, I leave here some references to books that will be useful for you:

• Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin)
• Refactoring: Improving the Design of Existing Code (Martin Fowler)

Finally, if you are a frontend developer and you like React, this book is great for getting started with TDD:

• React Test Driven Development (Daniel Irvine)

To display the loading bar, we will use NProgress:

npm install nprogress

The next thing we will do is to create a custom hook that we will call useLoading. Inside the hook, we will subscribe to the router events. When the path changes, we will run NProgress.start() to show the loading bar and when the path has finished loading, we will run NProgress.done() to hide it.

useLayout.tsx

import * as React from 'react'
import { useRouter } from 'next/router'
import NProgress from 'nprogress'

export const useLoading = () => {
  const router = useRouter()

  React.useEffect(() => {
    const handleStart = () => NProgress.start()
    const handleComplete = () => NProgress.done()

    router.events.on('routeChangeStart', handleStart)
    router.events.on('routeChangeComplete', handleComplete)
    router.events.on('routeChangeError', handleComplete)

    return () => {
      router.events.off('routeChangeStart', handleStart)
      router.events.off('routeChangeComplete', handleComplete)
      router.events.off('routeChangeError', handleComplete)
    }
  })
}

To display the loading bar on all pages, we need to add the NProgress styles globally. Remember to import that .css file into _app.tsx:

/* NProgress */

/* Make clicks pass-through */
#nprogress {
  pointer-events: none;
}

#nprogress .bar {
  background: #29d;

  position: fixed;
  z-index: 1031;
  top: 0;
  left: 0;

  width: 100%;
  height: 2px;
}

/* Fancy blur effect */
#nprogress .peg {
  display: block;
  position: absolute;
  right: 0px;
  width: 100px;
  height: 100%;
  box-shadow: 0 0 10px #29d, 0 0 5px #29d;
  opacity: 1;

  -webkit-transform: rotate(3deg) translate(0px, -4px);
  -ms-transform: rotate(3deg) translate(0px, -4px);
  transform: rotate(3deg) translate(0px, -4px);
}

/* Remove these to get rid of the spinner */
#nprogress .spinner {
  display: block;
  position: fixed;
  z-index: 1031;
  top: 15px;
  right: 15px;
}

#nprogress .spinner-icon {
  width: 18px;
  height: 18px;
  box-sizing: border-box;

  border: solid 2px transparent;
  border-top-color: #29d;
  border-left-color: #29d;
  border-radius: 50%;

  -webkit-animation: nprogress-spinner 400ms linear infinite;
  animation: nprogress-spinner 400ms linear infinite;
}

.nprogress-custom-parent {
  overflow: hidden;
  position: relative;
}

.nprogress-custom-parent #nprogress .spinner,
.nprogress-custom-parent #nprogress .bar {
  position: absolute;
}

@-webkit-keyframes nprogress-spinner {
  0% {
    -webkit-transform: rotate(0deg);
  }
  100% {
    -webkit-transform: rotate(360deg);
  }
}
@keyframes nprogress-spinner {
  0% {
    transform: rotate(0deg);
  }
  100% {
    transform: rotate(360deg);
  }
}

Finally, we will import our custom hook in each page. A good idea is to create a Layout component that imports the hook and receives the content of each page as children. This way we reuse it in a more comfortable way.

import Head from 'next/head'
import { useLoading } from 'components/useLoading'

type LayoutProps = {
  children: React.ReactChild | React.ReactChild[]
  title: string
}

export const Layout: React.SFC<LayoutProps> = ({ children, title }) => {
  useLoading()
  return (
    <>
      <Head>
        <title>{title}</title>
        <meta
          name="viewport"
          content="width=device-width, initial-scale=1"
        ></meta>
      </Head>
      {children}
    </>
  )
}