One AI Setup, Two Worlds: How I Use AI Agents as a Tech Lead and as an Entrepreneur

I wrote before about what actually works with AI in the developer workflow. That post was about principles. This one is about the setup itself: the tools that run on my machine every day, how the same setup serves two very different contexts, and the rules I follow so that it stays a tool and not a liability.

The two contexts are my day job as a Tech Lead and Arupo, the company I’m building as a partner, plus a handful of personal projects. Very different constraints, one engineer, one laptop.

The Foundation: Configure Once, Use Everywhere

The biggest mistake I see is treating every AI tool as a separate island: one set of instructions in one editor, different habits in another, nothing shared between them. I went the other way. There is one foundation, and every agent sits on top of it.

• A shared harness. I use Gentle AI to give every agent the same workflow, the same persona and the same review rules. It’s configured for Claude Code, Codex, OpenCode, Gemini and Copilot. Whichever agent I open, it works the same way.
• Persistent memory. Engram stores decisions, bug fixes, discoveries and preferences across sessions and across agents. When I come back to a project after two weeks, the agent doesn’t start from zero, and neither do I.
• A code map. Codegraph indexes each repository so an agent can understand the structure without reading file by file. That matters when the codebase is large and the context window is not.
• Current documentation. Context7 gives agents the up-to-date docs of the libraries I use, instead of whatever version they memorized during training.
• A second AI terminal. Pi, with the Gentle Shell, is where I run longer orchestrated work, with profiles for different models.
• A guardian on commits. A pre-commit reviewer checks changes before they land.
• A comfortable environment. Ghostty, Starship and the Gentleman dotfiles. It sounds cosmetic, but you spend the whole day there.

None of these is magic on its own. The value is that they are wired together: the same rules, the same memory, the same way of working, regardless of the agent or the project.

Two Worlds on One Machine

Here is the part people rarely talk about. My job and my company must never mix. Different accounts, different identities, different rules about what can leave the machine.

So the separation is automatic, by folder. When I enter my personal projects folder, the personal AI profile and my personal git and SSH identity activate on their own. When I enter the work folder, the corporate AI profile and the corporate git identity take over. I don’t have to remember to switch, and that is the point: a rule you have to remember is a rule you will eventually break.

It isn’t perfect, and I know where the gaps are. The GitHub CLI, for example, doesn’t switch accounts per folder; it uses one global session. Knowing the gaps of your own setup is part of owning it.

At Work: Leading Inside the Constraints

A company has rules about tools and data, and they exist for good reasons. My rule is simple: the way of working travels with me, the company’s policies decide which tools I can use. I adapt the setup to fit those policies, never the other way around.

But the bigger change at work isn’t technical. It’s how I spend my time as a Tech Lead. Agents take a lot of the mechanical work: exploring an unfamiliar service, drafting a migration, writing the boring tests. That gives me more time for what a Tech Lead is actually for: design decisions, code reviews, unblocking the team, incidents and postmortems.

One thing does not change: ownership stays human. An agent can propose a change to a production service. I’m the one who answers for it at 3 a.m.

At Arupo: Speed Without Lowering the Bar

In my own company the constraint is the opposite. There are no corporate restrictions, but there is very little time and a very small team. AI is what lets a small team ship like a bigger one, as long as the quality bar doesn’t drop.

The best example is the website you’re reading. In a few work sessions it went through:

• A full redesign with English and Spanish versions.
• An SEO cleanup.
• Security hardening: a Content Security Policy generated at build time, with a check that fails the build if an inline script is missing from it.
• A migration from Astro 5 to Astro 7.
• An accessibility pass to meet WCAG AA contrast, and a dependency audit taken down to zero known vulnerabilities.

Each of those shipped as its own pull request, with preview deploys, before reaching production. The agents did most of the typing. I made every decision that mattered: what to upgrade and what to leave alone, which security trade-off to accept, when something was ready to merge.

The same setup runs my other projects: finance and fitness side products, a thesis, and the different repositories behind Arupo.

The Workflow That Ties It Together

Tools are the easy part. What makes this work is the process I follow with them, the same in both worlds:

1. Clarify first. If the request is ambiguous, the agent asks before it writes a single line.
2. Size the task. Small, well-understood changes are done directly. Large ones get tracked.
3. Write the spec. A large change gets a document: the requirements quoted exactly as I said them, a numbered task list and a log of decisions. Anyone, human or agent, can resume from it.
4. Tests first. When the behavior is testable, the failing test comes before the fix.
5. Small commits. Reviewable slices, never one giant diff that nobody can really review.
6. Review by risk. When a change touches security, data, contracts or deployments, an independent reviewer looks at it. When it doesn’t, I don’t pay for ceremony I don’t need.
7. I merge. Pushing, opening the pull request and merging remain my decisions. Always.

What Doesn’t Work (Yet)

To keep this honest:

• Tools break. Some integrations need re-authentication, others fail to connect. A setup this connected needs maintenance.
• Memory goes stale. A decision saved three months ago may no longer be true. Memory is context, not truth.
• Agents are confidently wrong. They will tell you a build passes when it doesn’t, or invent an API. That’s why every claim needs evidence: the test output, the build log, the diff.

Closing Thoughts

AI didn’t make me a different engineer. It amplified the one I already was. The fundamentals I learned over eight years, from network infrastructure to leading product teams, are exactly what let me direct these agents and catch them when they’re wrong.

The skill that matters now isn’t typing fast. It’s knowing what to ask, recognizing when the answer is wrong, and owning the result. That part is still, and will remain, ours.