Mmanish.pm
hi@manish.pm

How I build

Context Engineering
+ Agentic Execution

I build TrekMeet by giving AI agents the context to do a specific job, a plan to work from and a clear point to stop for review. The code matters. So does the information that lets the next agent pick up the work.

State as at September 2026

The working team

Each mission has an owner
and a boundary.

/Architect
Prepares the plan, then stops for approval.
/Engineer
Builds from the approved plan and reports the checks.
/CTO
Reviews the evidence and signs off.
/UX Partner
Makes the behaviour concrete before implementation.
/QA
Turns device observations into a report the team can act on.
The specialist roles

/Fixer investigates stubborn bugs. /Release Manager prepares the release. /Website Partner maintains the site. /Social Media Partner drafts the public story.

The human part

What stays
with me.

I choose what matters, review the proposed experience and approve work at agreed stages. I also test on real devices and on walks.

Passing a build doesn't tell me how a feature feels with a group on a trail.

A second provider

The process carries across.

Claude Code+Codex

Codex now works alongside Claude Code. I can run separate missions in parallel while keeping one source for the project rules. The roles and review points carry across; the provider is a choice within the process.

CTO review and shared project close-outs currently stay with Claude Code. The newer lane is being proven through actual missions. Some responsibilities still need to be validated on Codex.

Continuity

The next session
can pick up the work.

The mission brief names the job, the files it may touch and the evidence needed to finish.

  • Current stateA small set of files says where the work stands.
  • Domain rulesThe relevant rules supply the constraints.
  • Close-outDecisions are recorded; old detail leaves the working context.
  • OwnershipSeparate missions can run together. Shared records have one writer at a time.

From a recent build

I could try the design
before approving the spec.

I wasn't happy with how a recorded walk looked on TrekMeet's map. The UX agent made an interactive comparison, with the current and proposed designs side by side.

I could try the behaviour and return the settings that felt right. The agent could then fold that feedback into the proposal before it went to the CTO.

Read the original post

The six levels

How the work has changed, and what I am working towards.

  1. Level 1Earlier

    Manual

    AI wrote code in a browser. I moved it into the project and joined the pieces together.

  2. Level 2Earlier

    Assisted

    Tools could edit files, but I still ran the commands and managed the context. This stage produced the first Google Play beta, on an eight-year-old Windows laptop with cloud builds.

  3. Level 3Earlier

    Supervised missions

    Claude Code made a repeatable workflow possible: load context, prepare a plan, approve it, build and record the result. That rough beta grew into a product on Android and iPhone.

  4. Level 4Current

    Coordinated team

    Roles own different parts of the work. Missions can run in parallel across Claude Code and Codex, with review and device checks still in the loop.

  5. Level 5Next

    A continuous loop

    Remove the handoffs that wait for me to start the next step. Keep the product decisions and approval points deliberate.

  6. Level 6Ambition

    Founder operating system

    Extend the same discipline beyond engineering into support, community and growth. This is a direction, not a claim about today's operation.

Anatomy of a mission

A brief that makes
the next action clear.

The agent should know both what to do and when to stop.

  1. ObjectiveWhat needs to change, and why.
  2. Architecture decisionThe pattern agreed before implementation.
  3. Parallel work I ownAny founder action the mission depends on.
  4. Implementation stepsThe files and changes the agent should work through.
  5. BoundariesWhat the mission must leave alone.
  6. VerificationBuild checks and the relevant device observations.
  7. RisksWhat could go wrong, and how to handle it.

Illustrative session

A deliberate pause
before the build.

/startLoad current state, rules and the mission.

/architectPrepare the plan and the verification steps.

Stop for approval.

/engineerBuild the approved changes. Run the checks.

Review the resultRead the evidence. Complete the required device checks.

Close the missionRecord the decisions and the next action.

The sequence is an explanation of the process, not a live terminal feed.

TrekMeet reached a closed Google Play beta five months after the first commit, about three of those months actual build time. The method developed as that rough build became a product on both stores. There is still work to do, including getting the routine handoffs out of my day.