Every one of those moves is a handoff. Each time, the same question comes up: what does the next agent actually need to know?

The obvious answer is the transcript. That doesn’t work for long. This post is about a small AI DevKit command that tries to answer the question better, and about Jev, the model behind it.

The problem is state handoff, not context length

Coding agent sessions get long quickly. An hour of implementation work can produce hundreds of messages: the original instruction, clarifications, file reads, test runs, failed attempts, retries, status updates, and the occasional “let me check that again”.

Somewhere in there are the facts that matter:

• what the user asked for, including the constraints they added halfway through,
• which decisions were made, and why,
• which files changed,
• which commands ran and what they proved,
• what is still blocked,
• what the next step is.

They are mixed with a lot of noise. The same npm test output appears four times. A path the agent tried and abandoned takes up twenty messages. Status chatter (“Now I’ll look at the service layer”) says nothing a later reader needs.

When I work with a single agent, this is mostly an annoyance. The harness compacts the context, some detail gets lost, and I repeat myself.

In orchestration it turns into a reliability problem. If the manager hands an executor’s state to a reviewer and the handoff drops a constraint, the reviewer approves the wrong thing. If a resumed session loses the validation evidence, the agent reruns work or, worse, claims something passed when nobody checked. A bigger context window doesn’t fix this. What fixes it is choosing the right state to pass on.

Jev in one sentence

Jev is a model from TypeSafe that takes unstructured input and returns typed decisions, fast.

TypeSafe calls it a System One Model and sums up the idea as “unstructured state in, typed probabilistic decisions out”. You don’t ask Jev to write. You give it a piece of state and a set of typed questions: pick one of these categories, give me a probability for this yes/no. It answers in that shape, with a probability or confidence attached.

According to TypeSafe, that narrow focus buys a few things:

• Type-safe answers. The output always matches the schema you asked for. TypeSafe goes further and says Jev “can’t hallucinate” for these queries, because the answer is constrained to the options you defined.
• Calibrated confidence. Every answer comes with a probability, and TypeSafe says higher confidence means higher accuracy.
• Latency. TypeSafe reports 70–500 ms end to end, and says that is 40 to 200x faster than frontier chat LLMs for “System One shaped” queries.

I haven’t benchmarked these numbers carefully, so treat them as TypeSafe’s claims. What matters for this post is the shape: Jev isn’t competing with chat LLMs at writing code or explaining things. It does the small, frequent judgement calls that sit between those bigger steps.

Structured output isn’t new

I want to be careful here, because it is easy to present this as a brand-new idea. It isn’t.

Jev doesn’t introduce the idea of structured AI output. Engineers have been moving toward “AI as a structured-data engine” for a while, with JSON mode, tool calling, and schema-constrained decoding.

Last year I wrote The turning point in AI. The first point in that post was that AI isn’t new. What changed was access, and with it, how engineers build.

The example I used was a weather app. The old way: an engineer writes the integration by hand. The early-AI way: the engineer asks an LLM to help write that same integration code. The shift I cared about was a third option: ask the model directly for the temperature, humidity, wind speed, and chance of rain for a location, in a structured format, and build the app around that output. In that post I put it as “Treat AI as an engine you can build around. Prompting becomes programming”.

Structured output was the important part then, and it still is. Once a model returns clean JSON instead of a paragraph, you can put it inside a program. You can branch on it, store it, test it, and pass it to the next step.

What Jev changes is the cost of each call and what the call returns. If a typed decision takes a few hundred milliseconds and comes back with a calibrated probability, you can afford to ask it many times inside a loop, not just once at the edge of a user interaction. Classifying every message in a session stops being an expensive batch job and becomes something you can simply do.

That’s the part I find exciting: an old idea that is now cheap enough to use in places where it used to be too slow.

Why session compact needs a typed decision layer

A normal summary keeps the story of a session. For continuing work, I don’t need the story. I need the operational facts.

So the first design question for session compact was: what should survive?

Keep:

• user instructions and constraints,
• decisions,
• code changes,
• command evidence,
• validation evidence,
• blockers and open questions,
• the next step,
• facts worth proposing as long-term memory.

Drop:

• routine status updates,
• duplicated tool output,
• abandoned exploration that led nowhere,
• anything sensitive, such as tokens, keys, and credentials.

Written that way, this is a classification problem, not a writing problem. For every event in the session I want answers to four questions:

1. Which category is this?
2. How important is it for continuing the work?
3. Should it survive compaction?
4. Does it contain something that shouldn’t be stored?

Each question has a small, fixed set of possible answers. That is exactly what Jev is built for. The categories AI DevKit uses are:

• user_instruction
• decision
• code_change
• command_evidence
• validation_evidence
• blocker
• next_step
• memory_candidate
• discard

Once every event has typed labels, building the compact artifact doesn’t need another model call. Plain code can do it.

How AI DevKit implements it

The command lives under the existing agent session namespace:

# Find the session you want to compact

npx ai-devkit@latest agent sessions --all

# Human-readable handoff

npx ai-devkit@latest agent session compact --id <session-id> --format markdown

# Machine-readable handoff for another agent or a script

npx ai-devkit@latest agent session compact --id <session-id> --format json

Markdown is the default. If the same session ID exists for more than one provider, --type narrows the lookup (claude, codex, gemini_cli, opencode, pi, and others).

Here is the pipeline:

A real run: compacting the session that built this feature

For a real example, I compacted the Codex session that built this feature. A manager agent handed the requirement to a Codex executor, and that executor took it through requirements, design, planning, implementation, tests, commit, rebase, and send PR. It ran for a few hours of wall-clock time.

The adapter returned 55 messages (9 user, 40 assistant, 6 system). Jev classified all of them sequentially in about 0.36s.

Here is how the size changed at each stage. Token counts use the o200k_base tokenizer, so treat them as estimates rather than any specific model’s exact count.

The raw file isn’t a fair baseline. Most of its 5.6 MB is event logs, tool calls and outputs, encrypted reasoning, and Codex’s own compaction records, and no model ever reads all of it at once. The numbers I care about are these two:

• Against the conversation Jev saw: 21.6K → 5.9K tokens, about 73% smaller.
• Against what Codex was actually holding in context at the end: 130.6K → 5.9K tokens, about 95% smaller. A fresh agent can start from roughly 6K tokens instead of inheriting a context that was half full of a 258K window.

Why this matters for orchestration

Once agents start working together, communication is part of the product. Here is where compact fits in the loop I use every day:

A few things change once handoffs carry compact state instead of transcripts:

• The manager stays small. It doesn’t have to read every executor transcript to know where things stand. It reads intent, current state, evidence, and next step.
• Reviewers start from facts. They get the constraints and the validation evidence up front, instead of digging through the transcript for them.
• Resuming is cheaper. A stale session can restart from its resume prompt instead of rereading hours of noise.
• Memory gets better input. Memory candidates come out as a separate list, so a memory skill can review them instead of me remembering to extract them.

A good handoff isn’t a longer summary. It’s the right state, chosen carefully. Session compact is a small primitive. Multi-agent setups become dependable through small primitives like this one.

Try it

If you’re building coding-agent workflows, and especially manager/executor/reviewer loops or long-running tasks that span sessions, try AI DevKit.

# Set up AI DevKit

npm i -g ai-devkit

ai-devkit setup

# See the agents and sessions it can discover

ai-devkit agent sessions --all

# Get a Jev key from TypeSafe, then compact a session

export TYPESAFE_API_KEY=YOUR_API_KEY_HERE

ai-devkit agent session compact --id <session-id>

Run it on a long session you already have and compare the result with what you’d have written by hand for the next agent. If the compact misses something you needed, or keeps something you didn’t, I’d like to hear about it. That feedback is how the categories and filter will improve.

The code is on GitHub. If my sharing is helpful to you, subscribe to my blog. I share what I learn while building real systems with AI in the loop. You can also follow me on X or Threads for more thoughts and ongoing experiments.

Sources

• TypeSafe, Introducing System One Models and Jev. Latency, hallucination, and calibration claims in this post come from this source.
• Codeaholicguy, The turning point in AI, May 2025.

I understand why people ask. Both can extend what an AI agent can do. A skill can include scripts that call APIs, while an MCP server can expose tools that call those same APIs. They can look like two ways of solving the same problem.

But I don’t think one is going to kill the other. They sit at different layers of the architecture, and they become more useful when we combine them.

Start with the agent

Before comparing MCP and skills, it helps to look at what an AI agent needs to do useful work. A model can reason about a request and generate a response. But reasoning alone is not enough, I also explained more detail in Why does MCP matter?.

The agent also needs to know:

• What process should I follow?
• What information can I access?
• What actions am I allowed to take?
• How should I use those capabilities safely?

Skills and MCP help answer different parts of those questions.

The simplest way I think about it is:

A skill teaches the agent how to do something. MCP gives the agent a standard way to access something.

That distinction is not perfect, but it is a useful place to start.

A skill is the instruction layer

An agent skill is usually a folder containing a SKILL.md file. That file describes what the skill does, when the agent should use it, and what process it should follow.

A skill can also include:

• Reference documents
• Templates
• Examples
• Scripts
• Other supporting assets

For example, a spreadsheet skill might tell the agent how to inspect a workbook, preserve formulas, format the output, and verify the final result. It could also include scripts for manipulating spreadsheet files.

The important part is that the agent gains a method to do things.

Skills are also designed to load progressively. The agent can first see a skill’s name and description, then load its full instructions only when the task requires them. This lets an agent have access to many specialized workflows without putting every instruction into its context at once.

In many tools, skills live on the local filesystem. This makes them easy to inspect, edit, commit to Git, and customize for a project, and some time it fragmented between different tools. That also the reason why I built AI DevKit skills management, so that we can manage skills consistently between different tools.

MCP is the integration layer

MCP, or Model Context Protocol, provides a standard way for an AI application to communicate with external tools and data sources.

Instead of every AI client building a custom integration for GitHub, Google Drive, Slack, or an internal database, it can connect to an MCP server. The server advertises the capabilities it supports and accepts structured requests from the client.

This separation matters from an engineering perspective.

The team operating the MCP server can update its implementation, fix bugs, change an internal API, or improve how it talks to the underlying service. Clients do not need to understand those internal changes, provided the MCP contract remains compatible.

MCP can also provide a more suitable boundary for concerns such as:

• Authentication and authorization
• Input and output schemas
• Centralized deployment
• Logging and observability
• Live data access
• Shared capabilities across multiple agents

MCP servers are not necessarily remote. MCP supports local communication between processes as well as communication with remote servers over HTTP. MCP architecture overview.

So the difference is not simply local versus remote. I personally believe it is closer to instructions versus integration.

Where the overlap becomes real

The boundary gets blurry when a skill includes executable scripts.

Imagine a skill containing a script that calls the GitHub CLI. If the user has already authenticated the CLI, the agent can use that script to open an issue. An MCP server could expose an open_issue tool that produces the same result.

In that specific case, a skill script and an MCP tool may appear interchangeable. For a local coding agent running on your laptop, they sometimes are. This is why the “skills replace MCP” argument is not completely unreasonable.

A skill can be faster to create and easier to distribute. If the agent already has filesystem and command-line access, adding an MCP server for one small operation may create more infrastructure than the task needs. But the tradeoff changes when the capability must be shared across many agents or users.

If you need centrally managed authentication, consistent permissions, production monitoring, live data, and an implementation that can be updated in one place, an MCP server becomes much more valuable.

They solve different parts of the same problem

Here is the comparison I find most useful:

These differences also show why they fit together so naturally.

A skill might tell an agent how to investigate a customer complaint:

1. Find the customer and confirm their identity.
2. Retrieve recent support tickets.
3. Check relevant transactions.
4. Compare the evidence.
5. Summarize the likely cause without exposing sensitive data.

MCP servers could provide access to the support system, transaction database, and customer records.

The skill owns the workflow. MCP provides the connections.

Without the skill, the agent has tools but may not know the right process. Without MCP, the agent understands the process but may not have access to the information needed to complete it.

If my sharing is helpful to you, subscribe to my blog. I share what I learn while building real systems with AI in the loop. You can also follow me on X or Threads for more thoughts and ongoing experiments.

The executor follows the dev lifecycle, implements the change, verifies it, and often creates the pull request without much intervention from me. I check progress with the manager instead of jumping between every agent session. When the pull request is ready, I review it, give feedback if needed, and merge it.

This is what lets me work on several things at the same time without turning my terminal into a wall of tabs.

I am not always at the keyboard either. When I step away, I connect the manager agent to Telegram and continue working with the same session from my phone.

AI DevKit gives me an agent manager, a shared operating model, and enough common context for different harnesses to work as one team.

I'm running Claude Code, Codex, and Gemini CLI in parallel.

The worst part isn't the token cost. It's the tab switching.

AI DevKit's Agent Console fixes this. One view, all your agents, send messages without leaving, quick hotkey to focus when you need detail.

Works in iTerm2,… pic.twitter.com/3VHg8LIUBa

— Hoang Nguyen (@codeaholicguy) May 28, 2026

The agent console

The main interface for me is the AI DevKit agent console.

The console gives me one place to open, message, and monitor agents across different harnesses. I can see what is running, which agent is waiting, and where I need to step in.

I still use commands such as agent list, agent detail, and agent send, but mostly for debugging, automation, or inspecting something the console does not make obvious. They are the low-level controls, not the center of my workflow.

I did not want a collection of commands that made me a faster dispatcher. I wanted an operating environment where one agent could manage other agents while I stayed focused on the problem.

The manager does more than route messages. It keeps track of the goal, the active workstreams, dependencies between agents, and anything waiting for a decision. It also checks whether an agent claiming completion has actually produced a verified result.

I also mentioned in the previous post why I have so many executor types. Basically, I want to make full use of my subscriptions while also taking advantage of what each executor is good at and being able to run different models.

The manager follows me to Telegram

The agent console is my main interface when I am at the computer. When I am away from the keyboard, I use the AI DevKit channel connector.

I select the manager agent in the console and connect it to my configured Telegram channel. The bridge runs in the background, so I can close the terminal view and keep talking to the manager from my phone. I also have the same AI DevKit stack running on a VPS so that I can chat with the agent manager 24/7.

Your AI agent no longer has to sit inside your terminal.

Pi integration is now available in AI DevKit.

Start a Pi session in Agent Console, or remote control it from Telegram with one click. https://t.co/tt6M4nhR3O pic.twitter.com/MRtHq4yhgz

— Hoang Nguyen (@codeaholicguy) June 13, 2026

This is still the same manager session. Telegram is simply another transport into it. The manager keeps its working context, access to the filesystem and memory, and the ability to coordinate executor agents.

From Telegram, I can ask for progress, answer a question that is blocking an executor, give feedback, or ask the manager to start another piece of work. I do not need to wait until I am back at my desk to keep the orchestration loop moving.

The equivalent low-level command is:

ai-devkit channel start telegram \

--agent <manager-name> \

--daemon

I normally connect it from the console. The command is useful when I am debugging the bridge or automating the setup.

I encode the workflow in skills

Anything I expect to repeat becomes a skill.

This is a large part of how I keep different harnesses consistent. Codex, Claude Code, OpenCode, Pi, or any different harnesses have different capabilities and session behavior, but they can load the same engineering process from the repository.

The skills I use heavily for this workflow are:

• agent-management for starting, selecting, inspecting, and stopping agents safely
• agent-communication for sending assignments, reading recent context, and relaying results between agents
• agent-orchestration for the repeated supervision loop: check progress, unblock agents, coordinate dependencies, and verify completion
• dev-lifecycle for moving a change through requirements, design, planning, implementation, testing, and review
• verify for requiring fresh evidence before an agent says the work is done

The manager knows how to manage because that behavior is encoded in skills. The executor knows how to take a requirement through to a pull request for the same reason.

This saves me from writing a giant orchestration prompt every morning and makes the process reusable. If I replace Codex with another harness tomorrow, I do not want to redesign how my team of agents works.

The filesystem and memory are the shared context

Delegation fails when the new agent starts with an empty head.

The filesystem solves part of this. Source code, requirements, design decisions, plans, test results, and implementation notes live in files that every agent can read. An executor does not need the entire brainstorming transcript if the outcome has already been captured in a clear requirement and plan.

The filesystem is not enough, though. Some context does not belong in the codebase:

• a recurring repository convention that is easy to miss
• a decision made during an earlier task and the reason behind it
• a known failure pattern and the verified way to avoid it
• a personal workflow preference that applies across projects

I use AI DevKit memory for this layer. It stores narrow, reusable knowledge in local SQLite. Agents search it when a task needs context instead of loading everything into every session.

Memory is the key layer that lets different harnesses start with the same understanding. Codex may have one conversation history and Claude Code another, but both can read the same files and retrieve the same durable knowledge.

I think of the context model like this:

• Filesystem: current state and explicit project artifacts
• Memory: durable decisions, conventions, and verified lessons
• Session: temporary reasoning and the conversation happening now

Keeping these separate also prevents memory from becoming a dumping ground. I do not store raw conversations, temporary progress, or guesses. If a future agent is unlikely to reuse it, it does not belong in memory.

My actual day-to-day loop

1. Start a manager

I usually start a Codex agent as the manager and keep that session alive. It becomes my main interface for the work, even when the actual implementation happens elsewhere.

The manager has the agent-management, agent-communication, and agent-orchestration skills. Actually, in my setup, these skills are installed globally. This gives it the ability to create agents, inspect their state, send follow-up instructions, and supervise work across several passes.

I still own the outcome. The manager owns the coordination loop.

2. Brainstorm before creating workers

I use the manager as a thinking partner first. We explore the problem, challenge assumptions, compare approaches, and narrow the idea.

I do not spawn an executor for every thought. That would create activity, not progress. I wait until there is something worth handing off: a requirement to develop, an investigation to run, a design to review, or a plan ready to execute.

This is also where human judgment has the most leverage. Agents can execute a well-framed task remarkably well. They are much less useful when several of them are confidently solving the wrong problem in parallel.

3. Ask the manager to create the right executor

Once the direction is clear, I tell the manager what I want executed. Sometimes I name the harness. Other times I describe the demand and let the manager choose between Codex, Claude Code, Pi, or another available agent.

A typical instruction is closer to this than a long shell command:

We have agreed on the requirement and approach. Create an executor agent in an isolated worktree, hand over the relevant context, and have it continue the dev lifecycle through implementation, testing, review, and PR creation. Monitor it and tell me when you need a decision or when the PR is ready.

The handoff includes the objective, scope, relevant files, constraints, validation expectations, and the artifact the executor should produce. The shared filesystem and memory carry the rest of the context.

The manager also prevents two executors from editing the same files at the same time. Parallel work needs clean boundaries or separate worktrees. Otherwise, the time saved during implementation comes back as conflict resolution.

4. Let the manager supervise

After the handoff, I usually move on to another idea or another workstream.

I had Claude Code and Codex working together like a real software team.

In the last video, I showed a simple setup: one Claude Code agent orchestrating other agents.

This time, I pushed it further.

I used ai-devkit agent orchestration to run a small “team”:
– Leader: Sonnet… https://t.co/76PA3hvK7C pic.twitter.com/9lziHWn8cX

— Hoang Nguyen (@codeaholicguy) April 8, 2026

The manager runs the orchestration loop. It checks agent status, inspects anything waiting or stale, relays necessary information, and sends corrections without duplicating instructions. If one executor depends on another, the manager sequences the work.

I check in with the manager rather than opening every executor session:

What is the current progress? Is anything blocked or waiting for me?

Most updates do not need my involvement. I care about exceptions: a product decision, an unresolved conflict, repeated failures, a security-sensitive action, or a result that cannot be verified.

This is where agent orchestration becomes different from launching a few background processes. Someone, in this case the manager agent, owns the loop until the work is complete or genuinely blocked.

5. Step into the executor when needed

Even with a manager, I sometimes open the executor session from the console and get involved myself. This can easily be done by choosing the agent in the AI DevKit Agent Console and pressing “o”.

I usually do this when the agent is drifting, a technical trade-off needs a quick back-and-forth, or I want to steer the implementation before it goes too far. Direct interaction has more bandwidth than relaying every detail through the manager.

Once the direction is clear again, I leave the executor to continue and let the manager resume supervision. The manager remains my default coordination path, while direct access is always available when it is faster.

6. Review the pull request

For a well-prepared task, the executor can often complete the dev lifecycle and create the pull request on its own.

I still review every pull request as an engineer: does it solve the original problem, are the trade-offs acceptable, is the diff understandable, and is the verification strong enough?

If I have feedback, I give it to the manager. The manager can send the work back to the same executor or create another review pass. Once I am satisfied, I merge.

My role moves up a level. I spend more time on framing, judgment, and review, while agents handle more of the execution and coordination.

How I choose a harness

I do not assign permanent job titles to tools. Codex is not always the implementer, and Claude Code is not always the reviewer.

I choose based on the work, the context already available, the model that I want to use, and what I need from that session. I may also want a different harness for a fresh perspective. The choice can change as the tools change.

This is another reason the shared layer matters. The dev lifecycle, project memory, and task artifacts should survive a change in harness; I might stop the execution in the middle and continue the process with a different harness. Tool preference should not become workflow architecture.

What makes the workflow scale

The practical benefit is that I no longer need to personally carry every task from idea to pull request in one continuous block of attention.

While one executor implements a feature, another can investigate a production issue, and I can brainstorm the next idea with the manager. I return when a decision or review needs me.

There are still limits, such as parallel work increases review load and poorly framed tasks fail faster. A manager without strong skills becomes a message-forwarding bot.

A few principles keep the setup useful:

• One manager owns the coordination loop.
• Executors receive bounded work and clear artifacts.
• I can step into an executor session when direct steering is faster.
• Skills carry the process across harnesses.
• Files and memory carry shared context across sessions.
• Worktrees or file boundaries isolate parallel changes.
• Fresh verification is better than an agent’s completion message.
• The human owns the final decision.

The engineer remains responsible, but spends attention in different places.

Start with a manager and one executor

If you want to try this workflow, start small:

npx ai-devkit@latest setup

npx ai-devkit@latest agent console

Choose the harnesses you already trust. Start one manager and give it the agent orchestration skills. Brainstorm one real task, capture the result in files, and ask the manager to create one executor to carry it through the development lifecycle.

Then watch where the handoff loses context. Encode the repeated fixes in skills. Store durable decisions in memory. Add another executor only when the first loop is reliable.

If my sharing is helpful to you, subscribe to my blog. I share what I learn while building real systems with AI in the loop. You can also follow me on X or Threads for more thoughts and ongoing experiments.

In this post, I’ll share what I learned from digging into Claude Code hooks.

Claude Code has 27 hook events. I went through all of them.

Most are not worth your time, a handful are useful, one or two can change how you use the tool.

The important thing to note is that hooks let you stop relying on the model to remember your rules. Instead, you can put those rules around the agent.

How hooks work

You put something like this in .claude/settings.json:

{

"hooks": {

"PreToolUse": [

{

"matcher": "Bash",

"hooks": [

{ "type": "command", "command": "/path/to/hook.sh", "timeout": 30 }

]

}

]

}

}

When the event fires, Claude Code runs your command, pipes JSON to stdin, and reads JSON back on stdout.

The input includes the event name, session id, transcript path, cwd, and event-specific fields.

Your stdout decides what happens next. You can abort with continue: false, deny the tool with decision: "block", or inject text into the next model turn with hookSpecificOutput.additionalContext.

Exit 0 with empty stdout is a no-op. Non-zero exits show up in the transcript as a hook error.

That’s it.

What I actually use

PreToolUse

Fires before every tool call. It can approve, block, or rewrite the input via updatedInput.

This is the one that matters most, because rewriting input is different from just observing. You can strip secrets out of commands before they run. You can refuse to run terraform apply outside an allowed directory.

A few examples:

• Regex scan for credentials or .env paths in Bash commands, then block with a reason
• Auto-redact tokens by rewriting the command instead of blocking it
• Hard-deny DELETE or DROP TABLE
• If the current branch is main and the command is git push, block

UserPromptSubmit

Fires when you hit enter. It returns additionalContext, which gets injected as a system message for the next turn.

This is basically a dynamic version of CLAUDE.md. Per-turn, conditional on whatever your script can compute.

Some ideas that work:

• Compliance reminders when the prompt mentions “user data” or “PII”
• A quick grep over the prompt that injects “relevant files: A, B, C”
• Refuse to submit if today’s API spend has crossed a threshold

PostToolUse

Fires after a tool call succeeds. It can return additionalContext for the next turn, or updatedMCPToolOutput to rewrite what the model sees.

This is a good place to enforce “always run test after an Edit”.

Small thing, but it removes a recurring class of stale-context bugs.

It is also useful for redacting secrets from Bash output before the model sees them. The model does not need to know your access tokens to keep working.

SessionStart

Fires on startup, resume, clear, and after compact. It can return additionalContext, initialUserMessage, or watchPaths.

The source field tells you what kind of start it is, so you can do different things on resume vs fresh boot.

watchPaths is the underrated part. It lets you register paths outside cwd so FileChanged fires for them. That is handy when a shared config repo lives somewhere else.

PermissionRequest

Fires when a tool call is about to ask you for permission. It can allow, deny, rewrite the input, or update persistent permissions.

This gets me off the “yolo allow everything” reflex without going full bypassPermissions.

Auto-allow ls, cat, grep, git status, etc. Defer everything else to the UI. In work repos, deny anything that writes outside the repo. In scratch repos, allow more.

The value is encoding the policy in code instead of clicking through the same prompts forever.

Useful in specific situations

These are not always wired up for me, but I reach for them when the situation calls.

PreCompact and PostCompact deserve a callout.

Long sessions get worse over time because compaction throws away things you wanted to keep. Pinning the current task and recent decisions across compaction is a small change, but it makes a visible difference if you do a lot of long-running work.

The rest

These exist. Most people will never wire them.

• StopFailure, audit-only, for when stop handling itself crashes
• SubagentStart, rarely useful alone, but pairs with SubagentStop
• Setup, fires on /init and maintenance. Useful if you ship /init templates
• SessionEnd, runs outside the REPL, cannot block exit, fails silently. Do not put critical cleanup here
• CwdChanged, FileChanged, building blocks for “watch this thing” workflows, mostly paired with SessionStart.watchPaths
• WorktreeCreate, WorktreeRemove, only fire for the worktree feature. The worktreePath response lets you override where worktrees get created
• ConfigChange, fires when settings files change on disk. Audit-only in practice
• Elicitation, ElicitationResult, MCP-only, for servers that request structured forms. Useful if you have a server that asks the same question every time
• TeammateIdle, TaskCreated, TaskCompleted, only relevant if you use Claude Code’s team features

Things that bit me

hookSpecificOutput is where the structured fields go. Older examples, and a lot of posts still floating around, put additionalContext, updatedInput, and watchPaths at the top level of the response. The schema moved. If your hook is not doing anything, check that first. Print the actual stdout and look at the shape.

Every PreToolUse adds latency to every tool call. Spawn cost on macOS is around 10 to 50ms. In a turn that makes 30 tool calls, that adds up. For logging hooks where you do not care about the response, set async: true and an asyncTimeout so the tool does not wait.

Hook commands run with your full shell. A project’s .claude/settings.json can register a SessionStart hook. Claude Code prompts you before trusting new project hooks, which is good. But it is still worth reading the hook before saying yes. If you ever clone an untrusted repo, look at its .claude/ before opening it.

If my sharing resonates with you, subscribe to my blog. I share what I learn while building real systems with AI in the loop. You can also follow me on X or Threads for more thoughts and ongoing experiments.

They jump straight into MCP, multi-agent systems, autonomous workflows, and every shiny demo on X. It looks exciting and also feels like the future. But for most engineers, that is not the right place to start.

The real path is much less glamorous.

You do not become good at agentic engineering by collecting tools. You become good at it by building the right skills in the right order.

Today, the tools are clearly moving in an agentic direction. Coding tools are no longer only giving autocomplete. They can now read codebases, edit files, run commands, create plans, work on branches, and connect to external tools. But the important part is not the tool itself. The important part is what kind of engineer you need to use these tools well.

To me, agentic engineering means doing software engineering with AI agents embedded across the workflow, not just for writing code, but also for understanding requirements, reviewing designs, planning work, implementing changes, testing, and connecting to tools and systems.

Why many engineers are learning this backward

A lot of people are trying to start from the advanced layer first.

They want to build agent swarms, wire up MCP servers, or run multiple coding agents in parallel before they can even manage one agent well. I understand why.

But in practice, most engineers still struggle with the basics. They do not give enough context. They do not define constraints clearly. They do not review generated code carefully. They trust output that only looks right. Then, when the result is messy, they blame the tool.

I think this is the wrong mental model.

Agentic engineering is still engineering. The tools changed, the responsibility did not. If you cannot guide one agent through a small feature with good context, good review, and good verification, adding more agents will usually create more noise, not more leverage.

What agentic engineering actually means

People use this term more and more now, so it is worth making it simple.

Agentic engineering is not just asking AI to write a function.

It is using AI agents across every phases of the software engineering workflow. That means an agent can help you understand requirements, review gaps, propose a design, turn the design into a plan, implement changes, generate tests, inspect the codebase, and connect to other tools or systems when needed.

That does not mean it replaces engineers. It means engineers now need to learn how to work with a system that can do more than autocomplete, and treat it like your co-workers.

Stage 1: learn to work well with one coding agent

This is where most engineers should start.

Pick one tool. It can be Cursor, Claude Code, Codex, Copilot, or whatever you already have access to. The point is not to chase the best tool immediately. The point is to build the habit of working well with one agent.

At this stage, focus on small and contained tasks.

Ask the agent to explain a piece of code you do not understand. Ask it to suggest a small refactor. Ask it to generate a unit test. Ask it to debug an error message. Ask it to implement a small helper function.

What you are really learning here is not prompting tricks. You are learning clarity.

• Can you describe the task in plain language?
• Can you break a problem into smaller pieces?
• Can you tell the agent what success looks like?
• Can you spot when the output is wrong or too shallow?

Fast output is not the same as good output. If you are early in your career, this stage is extremely valuable because it forces you to read code more carefully. It also shows you very quickly where your own fundamentals are weak.

Do not rush past this stage.

If you cannot manage one agent well, you are not ready for five.

Stage 2: learn context engineering

This is where the quality difference starts to show.

Most bad AI output is not caused by a weak model. It is caused by weak context. When engineers say, “AI is inconsistent” a lot of the time what they really mean is, “I gave it a vague task and hoped it would figure out the rest”.

Context engineering sounds fancy, but the core idea is simple: give the agent the information it actually needs to do the job well.

That usually means:

• what problem you are solving
• what constraints matter
• what the expected output looks like
• what patterns already exist in the codebase
• what edge cases matter
• what should not change

If the task is ambiguous, say so. If you are making assumptions, list them. If there are trade-offs, ask the agent to call them out before it writes code.

A lot of people think prompting is the key skill. I think context is the deeper one. A good engineer with average prompts but strong context will often get much better output than someone with clever prompts and weak problem framing.

Stage 3: learn review, verification, and testing discipline

This is one of the most important stages. AI makes it much easier to produce code quickly. That means the bottleneck is no longer typing speed. The bottleneck becomes judgment.

• Can you review the code properly?
• Can you tell if the abstraction is wrong?
• Can you see whether the agent handled edge cases, failure modes, backward compatibility, or long-term maintainability?

This is why I keep saying agentic engineering still sits on top of engineering fundamentals.

You still need to understand systems. You still need to reason about trade-offs. You still need to care about testing and quality. In some ways, these skills matter even more now because the volume of output is higher.

At this stage, build strict habits:

• review generated code line by line when the change matters
• ask what could break
• generate tests, then improve them
• compare the output against the original requirement
• run the code and verify behavior
• do not trust “should work”

One of the easiest traps with AI coding tools is that they often produce something that looks complete. The UI renders, tests pass, code seems reasonable. But software engineering is full of cases where something works and is still the wrong solution.

You need the discipline to catch that.

Stage 4: build repeatable workflows

Once you are comfortable with one agent, better context, and stronger verification, the next step is to stop working randomly.

This is where you move from scattered prompting to a repeatable workflow.

For me, the workflow still looks very familiar: requirement -> assumptions -> design -> plan -> implement -> review -> test -> verify

AI does not remove these steps. It just helps execute them faster.

That is a very important mindset shift. If your workflow is weak without AI, adding AI usually just helps you move faster in a messy direction. If your workflow is clear, AI can remove a lot of friction.

At this stage, start turning your habits into something reusable.

It can be a markdown checklist. It can be a set of reusable prompts. It can be command shortcuts inside your editor. It does not need to be fancy.

The goal is consistency. When you have a repeatable workflow, the quality of your AI-assisted work becomes much more stable. You are no longer relying on memory or improvisation every time.

Stage 5: connect agents to tools and real systems

Now we start getting closer to what people usually imagine when they hear the word “agentic”.

At this stage, the agent is not only responding to the text you paste into chat. It can access files, run commands, inspect code, search documentation, call APIs, or pull information from other systems.

This matters because real software engineering does not happen in one text box.

Requirements live in docs, tickets live in Jira, designs live in Figma, code lives in repositories, logs live somewhere else. Part of becoming good at agentic engineering is learning how to let agents work with this wider environment safely and usefully.

But notice the order. Tool use becomes powerful only after you already know how to frame work, review output, and maintain a good workflow. Otherwise, you are just giving a confused agent more ways to be confidently wrong.

This is the bridge from AI-assisted coding to real workflow-level leverage.

Stage 6: learn MCP when it solves a real problem

A lot of engineers want to start here because MCP is one of the hottest topics right now. I would not.

MCP matters, but it makes more sense after you already understand why tool integration matters in your workflow.

In simple terms, MCP is a standard way for AI systems to connect to tools and data sources. That is useful because once you have many integrations, ad hoc connections get messy very quickly.

So yes, MCP is important.

But no, it should not be the first thing to learn. If you do not already have a clear use case, MCP will feel like extra abstraction. Learn it when you can answer a more important question first: what real friction am I removing by connecting this agent to this tool?

Sometimes the right answer is MCP. Sometimes a CLI is enough. Sometimes a simple manual step is still the better trade-off.

Use the right level of complexity for the problem you actually have.

Stage 7: only then explore multi-agent workflows

This is the advanced stage.

Now you can start experimenting with workflows where different agents take on different parts of the work.

For example:

• one agent reads the codebase and summarizes the current state
• one agent proposes a plan
• one agent implements
• one agent reviews or looks for risks
• one agent explores an alternative approach

This can be powerful, but it can also get chaotic very quickly.

Because the moment you run multiple agents in parallel, a new bottleneck appears. The bottleneck is not coding anymore. It is context recovery, attention management, and judgment. Suddenly, the work is not limited by how fast code can be generated. It is limited by how quickly you can understand what each agent is doing and make a good call.

That is why I see multi-agent workflows as stage seven, not stage one. They become useful only after you already know how to manage smaller loops well.

What I would focus on first if I were junior or mid-level today

If I were early or mid-career and wanted to build agentic engineering skills, I would keep it very simple.

First, I would get good at one coding agent. Not ten. Not the most advanced stack. Just one. I would use it every day for small tasks until I learned how to guide it well and where it tends to fail.

Second, I would get much better at writing context.

I would practice turning vague tasks into clear problem statements with constraints, edge cases, expected outputs, and assumptions. This skill is useful even without AI, which is one reason I think it is such a strong investment.

Third, I would strengthen my review and testing habits.

I would treat AI output like code from a fast junior engineer: useful, often impressive, but still needing review, correction, and verification.

Fourth, I would build one repeatable workflow for myself.

It does not need to be perfect. It just needs to be consistent enough that I stop relying on random prompting every time.

Fifth, I would delay advanced orchestration.

I would not spend most of my time on multi-agent setups, complex MCP architecture, or fancy demos until I had a strong grasp of the basics.

That path may look slower, but I think it gets you useful faster.

Closing

I think agentic engineering will become a normal part of software engineering.

Not because every engineer will run a swarm of autonomous agents, but because the default workflow is already changing. AI tools are becoming more capable. They can read more, do more, and act more.

But the right response is not to chase everything new. The right response is to build the right skills.

Learn to work well with one agent. Learn to build context. Learn to review and verify. Learn to design repeatable workflows. Then learn how to delegate more.

That is how I think most engineers should learn agentic engineering.

If this perspective resonates with you, subscribe to my blog; it’s free. I share what I learn while building real systems with AI in the loop. You can also follow me on X or Threads for more thoughts and ongoing experiments.

Sometimes I have Claude Code working on one feature, Codex reviewing a plan, Gemini CLI exploring another direction, and another Claude session fixing a smaller issue in parallel. On paper, this sounds like the future of software engineering. One engineer, multiple agents, multiple streams of execution are happening at the same time.

And honestly, it is exciting.

For the first few minutes, it feels like I suddenly have a small engineering team around me. One agent can build, one agent can review, one agent can explore an alternative, one agent can check if the plan makes sense. Instead of waiting for one task to finish, I can start several pieces of work and let them run.

But after doing this for long enough, I realized the hard part is not starting more agents.

The hard part is keeping up with them.

The old productivity equation is changing

In the past, engineering capacity mostly scaled with people.

If we wanted to do more work, we hired more engineers. That gave us more hands, more thinking capacity, more reviews, more parallel execution, and more ownership. Of course, it also added communication overhead, meetings, planning complexity, alignment cost, and all the usual coordination problems that come with growing a team.

But the basic model was simple: more people meant more capacity.

AI changes that model.

With coding agents, one engineer can now start multiple streams of work at the same time. The amount of work we can attempt is no longer limited only by the number of engineers in the team. It also depends on how many agents we can safely direct, review, and coordinate. This is a big thing.

It does not mean headcount no longer matters. That is too simplistic. Great engineers still matter a lot because judgment, system understanding, product context, and ownership still sit with humans.

But the scaling model is changing.

In the future, the question may not only be “how many engineers do we have?” It may also be “how many agent workflows can these engineers safely orchestrate?”

The word “safely” matters because generating more code is not the same as creating more good software.

Why I started running everything at once

Part of my motivation is practical.

I already paid for multiple AI subscriptions. Claude, ChatGPT, Google AI, and a few different tools around them. I do not want to use them in a slow sequence: use Claude first, wait until I hit the limit, then switch to Codex, then switch to Gemini when something else runs out. That feels wasteful.

If I have multiple tools available, I want to use them at the same time. Not because every tool is equally good at every task, but because different tools have different strengths, speeds, limits, and behaviors.

Claude Code may be better for one kind of implementation. Codex may be useful for reviewing a plan or taking another pass at the same problem. Gemini CLI may give me a different perspective. Sometimes the value is not that one model is clearly better, but that they do not fail in exactly the same way.

So I started thinking less about “which tool should I use?” and more about “how do I compose these tools together?”

That is where things get interesting.

One agent can implement a feature, another can review the plan before implementation, another can generate tests, another can inspect the diff and look for edge cases, another can explore a simpler version of the same solution.

I am no longer just doing AI-assisted coding. It starts to look more like orchestration.

The first wall I hit was not code quality

I expected the first major bottleneck to be code quality.

That is still a real problem. AI-generated code can be functional but wrong. It can pass the happy path while missing the edge cases, it can create abstractions that look clean in isolation but do not fit the existing system, it can confidently change things it does not fully understand.

But surprisingly, that was not the first wall I hit.

The first wall was tab switching.

Personally, I use tmux heavily. I arrange agents by session, window, and pane. One session for a feature, one session for another experiment, one pane for a running server, one pane for tests, one pane for a coding agent, another pane for a review agent.

This works quite well when the number of active streams is small.

If an agent needs my attention once an hour, no problem. I can switch to it, read the output, make a decision, and move on.

But agents do not work at human speed.

They generate code fast, they ask for confirmation, they hit errors, they finish tasks, they need permission, they ask whether to continue, they suggest a plan, they wait for feedback. When that happens every few minutes, tab switching becomes more than a small annoyance.

I found myself jumping between sessions, trying to remember what each agent was doing, what I asked it to do, whether I had already reviewed its plan, whether the current output was good, and whether I still trusted the direction.

The visible problem was switching tabs, and the real problem was switching context.

More agents create more open loops

Every agent creates an open loop in your head.

One agent is working on the API layer, another is touching the frontend, another is reviewing tests, another is exploring a refactor, another is checking if your architecture plan makes sense. Each one has its own goal, assumptions, progress, risk, and current state.

The agent may remember its own context, but you still need to remember your context.

• Why did I start this task?
• What constraint did I give it?
• Did it follow the existing pattern?
• Did it make a decision I did not approve?
• Is this output still aligned with the original intent?
• Should I stop it now before it goes too far?

This is the part I think many people underestimate.

Running multiple agents does not mean there is more of you. Your attention does not automatically scale just because the execution layer scales. You may have five agents generating output, but there is still one human brain trying to understand, judge, and integrate that output.

That is the next bottleneck. The bottleneck is whether the engineer can safely navigate and orchestrate multiple agents without losing control of the work.

The engineer becomes the orchestrator

I used to think AI productivity was mostly about writing better prompts.

Prompting matters, but it is only the first layer. Once you move from one AI assistant to multiple agents, the skill changes. You are no longer only asking for code. You are managing work.

• You need to decide which task should be delegated.
• You need to split work into clear boundaries.
• You need to decide which agent should review which output.
• You need to avoid two agents making conflicting changes.
• You need to know when to interrupt an agent before it digs a deeper hole.
• You need to create verification loops so you do not become the only test system.

This feels much closer to engineering leadership.

A good tech lead does not randomly assign work to five engineers and hope everything magically merges at the end. They clarify the goal, define boundaries, create checkpoints, review important decisions, and make sure the pieces fit together.

Multi-agent engineering needs the same discipline. The difference is that agents move faster, produce more output, and can create more mess in less time.

Experiment 1: hierarchical orchestration

One experiment I have been working on is a hierarchical setup.

The idea is simple: instead of me directly managing every agent, one agent acts as the coordinator. It works like a team lead. It understands the goal, breaks down the work, delegates tasks to other agents, collects progress, and summarizes what needs my attention.

I had Claude Code and Codex working together like a real software team.

In the last video, I showed a simple setup: one Claude Code agent orchestrating other agents.

This time, I pushed it further.

I used ai-devkit agent orchestration to run a small “team”:
– Leader: Sonnet… https://t.co/76PA3hvK7C pic.twitter.com/9lziHWn8cX

— Hoang Nguyen (@codeaholicguy) April 8, 2026

In theory, this reduces the interruption cost.

Instead of five agents asking me five different questions, the coordinator can filter the noise. It can decide which updates are worth surfacing, ask one agent to review another agent’s plan, compare outputs, and tell me where the work is stuck.

This is powerful when it works. It changes the interaction model from “I need to monitor every agent” to “I need to monitor the system”.

But it also introduces a new problem: How much do I trust the coordinator?

If the coordinator misunderstands the goal, the whole group may move in the wrong direction. If it summarizes too aggressively, I may miss an important detail. If it delegates poorly, I may only discover the problem after multiple agents have already produced a lot of code.

So the coordinator agent does not remove the need for human judgment. It moves the judgment point.

Instead of reviewing every small step, I now need to review the coordinator’s decisions, assumptions, and summary quality. That is useful, but it is not free.

The lesson so far: hierarchy helps reduce direct noise, but it needs strong checkpoints.

Experiment 2: mission control for agents

The second experiment is a mission-control style interface.

The idea is to have one place where I can see all active agents, understand what each one is doing, switch to any of them, and talk to them directly without jumping across many terminal tabs.

I'm running Claude Code, Codex, and Gemini CLI in parallel.

The worst part isn't the token cost. It's the tab switching.

AI DevKit's Agent Console fixes this. One view, all your agents, send messages without leaving, quick hotkey to focus when you need detail.

Works in iTerm2,… pic.twitter.com/3VHg8LIUBa

— Hoang Nguyen (@codeaholicguy) May 28, 2026

This came from my own frustration with tmux.

Tmux is great. I still use it, but tmux was not designed specifically for managing AI agents. It helps organize terminal windows, but it does not understand agent state.

• It does not tell me which agent is waiting for input.
• It does not summarize what changed.
• It does not show which agent is blocked.
• It does not help me understand which task is risky.
• It does not tell me which session needs my attention first.

That is what I want from a mission-control interface, not a fancy UI for the sake of it. I want a lower-friction way to manage attention.

I want to glance at one place and know what is happening.

• Which agents are running?
• Which agents are waiting?
• Which agents have produced a diff?
• Which agents are stuck?
• Which agents need review?
• Which agents can continue without me?

This sounds small, but I think it matters a lot.

When the cost of navigation is high, you avoid checking. When you avoid checking, agents drift. When agents drift, review becomes harder. When review becomes harder, you either slow down or you merge things with less confidence.

A good mission-control layer should reduce the cost of staying on top of the work. You can try it out by running npx ai-devkit@latest agent console.

AI DevKit as my experiment foundation

This is also why I have been spending more time experimenting with AI DevKit. Not as “the answer” to everything, but as a foundation for experiments.

Once you start playing with multi-agent workflows, you quickly realize you need reusable building blocks. You need a way to manage agent sessions. You need a way to structure phases. You need a way to keep context organized. You need shared memory. You need a way to make experiments repeatable instead of hacking together a one-off script every weekend.

For example, having a foundation like an agent manager makes it easier to build higher-level workflows on top. I do not want to rebuild the basic plumbing every time I want to test a new orchestration idea.

That is the useful part. The product is not the point here. The research question is the point.

• How should engineers work when they have multiple agents running at the same time?
• How much autonomy should each agent have?
• When should an agent interrupt?
• What should be summarized?
• What should never be summarized?
• Which review tasks can be delegated to another agent?
• Where must the human stay directly involved?

I do not think we have the final answer yet. That is what makes it interesting.

The next tooling layer is not a better code editor

Most AI coding tools today still feel centered around one main interaction: human asks, AI responds.

That works for many workflows, but multi-agent work needs a different shape.

• We need tools that understand agent state, not just terminal output.
• We need attention routing, so the engineer is interrupted only when needed.
• We need review queues, so generated work does not disappear into random sessions.
• We need task boundaries, so agents do not step on each other.
• We need verification loops, so speed does not destroy confidence.
• We need better ways to compare parallel attempts at the same problem.
• We need summaries that preserve decision quality, not just compress text.

This is where I think the next wave of engineering tooling will go.

The future is not only a smarter code editor. It is an operating layer for agentic work. A place where engineers can define intent, spin up agents, observe progress, redirect work, review outputs, and keep ownership without drowning in context switching.

More output is not the same as more progress

There is a trap here.

When you first run multiple agents, it feels productive because many things are happening. It looks like progress. But output is not progress.

Progress means the system is moving closer to the right outcome. That requires judgment.

• If five agents generate five different implementations that do not fit the codebase, you did not become five times more productive. You just created five things to review.
• If one agent builds a feature and another breaks a shared abstraction, you did not save time. You moved the cost to integration.
• If agents produce code faster than your verification loop can handle, you are not accelerating engineering. You are accumulating uncertainty.

This is why I keep coming back to the same idea: AI makes execution cheaper, which pushes the constraint somewhere else.

For software engineering, I think the constraint is moving toward orchestration, verification, and attention.

Where I am now

I am still early in this exploration. I have some working experiments, some feel promising, some feel awkward.

That is fine. This is exactly the phase I enjoy. The interesting part is figuring out how humans and agents should work together when the number of active agents keeps increasing.

I do not think the best engineers in the AI era will simply be the ones who know how to prompt. They will be the ones who know how to decompose problems, assign work, create feedback loops, verify outputs, and keep ownership while multiple agents execute in parallel.

That is a different skill, and like every real engineering skill, it will take practice.

I also do not believe the future is as simple as “AI replaces engineers”. That framing is lazy.

A more realistic future is that one engineer may coordinate many agents. Those agents may write code, review plans, generate tests, inspect logs, compare designs, or explore alternatives. The engineer still owns the problem, judgment, and the final call. The shape of the job changes, less time typing every line by hand, more time deciding what should be done, how work should be split, what good looks like, and whether the result is safe enough to ship.

That future is exciting to me, but it will only work if we design the workflow carefully. Otherwise, we will not remove the bottleneck. We will just move it into the engineer’s head.

More agents, same human brain.

That is the problem I want to keep exploring.

If this perspective resonates with you, subscribe to my blog; it’s free. I share what I learn while building real systems with AI in the loop. You can also follow me on X or Threads for more thoughts and ongoing experiments.

A modern 10x engineer creates outsized impact by turning unclear problems into safe, shippable outcomes with less friction across the team.

AI helps with that, but only if the engineer knows how to use it well.

This is a practical follow-up. Not a framework or checklist, just a set of habits that matter more now if you want to create real leverage with AI.

Build strong fundamentals first

Do not skip the basics because AI can generate code.

This is the biggest trap I see. AI makes it easy to produce something that looks correct. It can generate a feature, a test suite, a migration, a script, or a full page in minutes.

But if you do not understand the system, you cannot judge the output.

You still need to understand how APIs evolve. You need to understand data modeling, transactions, caching, queues, deployment, monitoring, debugging, performance, and security. You need to know how production fails.

AI can help you learn faster, but it should not remove your ability to think.

If you are early in your career, use AI as a learning partner, not as a replacement for learning. Ask it to explain the code. Ask it why a design works. Ask it what can go wrong. Ask it to compare two approaches.

Then verify the answer yourself.

A 10x engineer with AI is not someone who depends on AI blindly. It is someone who understands enough to guide it, challenge it, and correct it.

Write better context

The quality of AI output depends heavily on the quality of context. Before asking AI to implement something, slow down and write the problem clearly.

What are we trying to solve? What is the current behavior? What should change? What should not change? What are the constraints? What are the edge cases? What is the blast radius? How do we verify the result?

This sounds boring, but it is where a lot of leverage comes from.

A vague prompt creates vague output. A clear context creates better execution. That’s exactly why I use the dev-lifecycle skill, it forces the right questions, so the context becomes clear before any execution starts.

For example, “Add a notification when an order is completed” is too vague. A better context would explain when an order is considered completed, which events trigger the notification, which users should receive it, what should happen if the notification fails, which channels are supported, and what tests should pass before shipping.

The goal is not to write a beautiful document. The goal is to make the work executable.

Good context helps humans. Good context helps agents. Good context reduces rework.

Use AI for understanding before implementation

When you enter an unfamiliar codebase, don’t rush to ask AI to change it. Ask it to explain the system first.

Where does this behavior start? Which files are involved? What is the data flow? What are the important abstractions? What patterns does this codebase follow? Where are similar implementations?

This habit matters a lot.

AI can make changes quickly, but fast changes in an unfamiliar system can be risky. You may fix one thing and quietly break another. You may follow the wrong pattern. You may add complexity to a place that already has a simpler convention.

Understanding first, implementation second. If you don’t know where to start, try this skill.

This is also how engineers become more domain-agnostic with AI support.

You may not know the system at the start. That is fine. But with structured knowledge, code search, team agents, and good prompts, you should be able to build enough understanding to contribute safely.

The mindset shifts from “this is not my domain” to “I don’t know this domain yet, but I can inspect it and find a safe path”.

Ask for tradeoffs, not only code

Many engineers use AI like a code generator. That is useful, but limited. A better habit is to use AI as a partner before asking it to write code.

Ask it:

• What are the possible approaches?
• What is the simplest version?
• What can go wrong?
• What is the risky part?
• What is the blast radius?
• What should we test?
• What would make this hard to maintain later?

These questions force better thinking.

They also make you slower in the right part of the process. You spend a bit more time before implementation, so you spend less time cleaning up a bad implementation later.

This is especially useful for junior and mid-level engineers. AI can expose you to tradeoffs you may not naturally think about yet.

But again, don’t accept everything blindly. Use the output as input for your own judgment.

Review AI output like production code

Treat AI-generated code like code written by a fast junior engineer.

It may be useful. It may even be impressive. But it still needs review.

Check whether the code actually solves the problem. Check whether it follows existing patterns. Check whether it handles failure. Check whether it creates hidden coupling. Check whether the test proves the right behavior.

Do not only review whether the code works locally. Review whether it should exist in the system.

That difference matters.

A feature can work and still be the wrong abstraction. A test can pass and still test the wrong thing. A refactor can look clean and still break a subtle behavior in production.

AI reduces implementation time, but it does not remove the need for engineering review.

If anything, review becomes more important because the volume of generated code can increase quickly.

Build verification loops

The faster you generate code, the more you need strong verification.

Tests matter. Type checks matter. Linters matter. CI speed matters. Logs, metrics, alerts, feature flags, canary rollout, and rollback plans matter.

AI speed without verification is just a faster way to create problems.

This is where strong engineering teams will separate themselves from noisy AI adoption.

A weak team may use AI to produce more changes. A strong team uses AI to produce more reliable changes.

The difference is verification.

For every meaningful change, ask yourself:

• How do I know this works?
• How do I know it did not break existing behavior?
• How do I know production is healthy after release?
• How do I roll it back if something goes wrong?

That is not bureaucracy. That is ownership.

Improve the agent after every task

This is one of the biggest mindset shifts.

Do not only use the agent. Improve the agent.

If the agent misunderstood a convention, update the rule. If it misses context, improve the documentation. If it repeated a mistake, improve the prompt. If it needed a command, script, or checklist, create one.

This is how one task turns into a multiplier.

The average engineer uses AI to finish the task in front of them. A high-leverage engineer uses the task to make the next task easier.

That small difference compounds over time.

After a few months, your agents become better. Your docs become better. Your workflows become clearer. Your team spends less time explaining the same thing again and again.

That is real leverage.

Build reusable workflows

A 10x engineer with AI does not repeat the same manual prompting forever.

If a workflow works, turn it into something reusable.

It can be a command. A prompt template. A checklist. A test harness. A script. A repo convention. A team agent. A small internal tool.

The format does not matter as much as the habit.

When you find yourself doing the same thing three times, pause and ask whether it should become a reusable workflow.

For example:

• Requirement review
• Design review
• Test generation
• Code review
• Migration planning
• Incident investigation
• Release note generation
• Monitoring checklist

These are all workflows that can be partially standardized.

The goal is not to remove human thinking. The goal is to remove repeated setup cost so humans can spend more energy on judgment.

Think in systems

Delivering a ticket is useful. Improving the system that delivers future tickets is leverage.

The new 10x engineer does both.

They ship the feature, but they also improve the path. They fix the bug, but they also improve detection. They complete the task, but they also improve the agent, the docs, and the verification around it.

This is the practical meaning of leverage thinking.

You are not only asking, “How do I finish this?”. You are also asking, “How do I make this easier, safer, or faster next time?”

That is the difference between being productive and creating leverage.

Stay accountable for the outcome

The last habit is simple, but probably the most important.

Own the outcome.

AI can help you move faster. It can help you understand code, generate tests, write implementation, summarize logs, and draft documentation.

But the responsibility still belongs to the engineer.

If the code breaks production, it does not matter that AI generated it. If the test misses the real edge case, it does not matter that AI wrote it. If the rollout has no monitoring, it does not matter that AI suggested the plan.

The engineer owns the final decision. This is why I think AI will not reduce the importance of engineering maturity. It will increase it.

The more leverage we have, the more judgment we need.

Closing

Becoming a 10x engineer with AI is not about learning a magic prompt. It is about building the habits that let you use AI safely and repeatedly.

AI can make you faster, but speed alone is not the goal.

The goal is to create better outcomes with less wasted effort, less coordination overhead, and more reusable leverage for the team.

That is what the new 10x engineer should look like.

If this perspective resonates with you, subscribe to my blog. I share what I learn while building real systems with AI in the loop. You can also follow me on X or Threads for more thoughts and ongoing experiments.

This is what I’d tell a teammate on day one if I had ten minutes. Patterns that change how fast you actually ship, and a few that will save you from yourself.

What Claude Code is, briefly

Claude Code is Anthropic‘s CLI agent. You run claude in a terminal, and it can read files, run shell commands, edit code, and call tools. There are extensions for VS Code and a desktop app. The CLI is where the interesting features live.

The mental model that matters: it’s a junior engineer who usually forgets things. Vague input gets vague output. Specific input (file paths, constraints, what you’ve ruled out, what “done” looks like) gets results you don’t have to redo.

Context and cache mechanics

This is probably the biggest lever on cost and latency, and almost nobody who hasn’t used the API understands it.

The prompt cache has a 5-minute TTL. When you send a message, Anthropic caches the prefix of your conversation. If your next message comes within 5 minutes, the cached prefix is essentially free. If you step away for a meeting and come back 20 minutes later, the entire conversation is re-read from scratch, uncached. Slower, more expensive.

Practical implication: if you’re about to step away, finish your turn at a clean boundary. Don’t leave a half-finished plan dangling. The next reply will replay the whole thing.

There’s an extended 1-hour cache too, but it’s opt-in. Default is 5 minutes.

/compact accepts instructions

Plain /compact summarizes your conversation and replaces the full history with the summary. It’s lossy, and the default summarization will often drop the wrong things. Better:

/compact preserve the auth refactor decisions and the failing test output, drop the file listings

You’re telling Claude what matters before it summarizes. Use it before context gets tight, not after.

/clear isn’t /compact

/clear wipes the conversation entirely. Use it when switching topics. Starting a new task with a clean slate keeps later prompts fast and prevents earlier wrong turns from biasing the answer. /compact summarizes. /clear resets.

Context drifts

If Claude went down a wrong path and you corrected it, that wrong path is still in the conversation, still affecting what it pattern-matches on. For non-trivial pivots, /clear and restart with what you learned. Hoping it “remembers the correction” gets unreliable past a certain point.

Resuming sessions

claude --resume lists your past sessions in the current project and lets you pick one up. Each session is stored as a .jsonl file under ~/.claude/projects/. Useful when coming back to a stalled task with full history intact.

Modes: plan, edit, accept-edits

Shift+Tab cycles between modes in an active session.

Plan mode is read-only. It can read files, grep, run safe shell commands, but it can’t write or edit. This is the mode you want for anything you don’t fully understand yet. It forces investigation before code gets touched. When the plan looks right, Shift+Tab back to edit mode and execute.

People underuse plan mode because muscle memory says “just ask and let it do it”. That works for trivial changes. For anything load-bearing, ten minutes in plan mode saves an hour of unwinding bad edits.

Accept-edits mode auto-accepts file edits without prompting per change. Good for refactors where you’ll review the full diff at the end anyway. Pair it with frequent git diff checks. You get the speed of unattended editing without losing the ability to catch a bad change before it compounds.

Thinking budgets

Claude Code supports keyword-triggered extended thinking. The keywords escalate:

• think is a small budget
• think hard is larger
• think harder is larger still
• ultrathink is the maximum

Use these for architectural decisions, hard debugging, or anything where Claude gave you a confidently wrong answer on a subtle question. Don’t use them for simple tasks, such as “rename this variable”. You’re paying for thinking tokens that don’t change the outcome. Some tasks fail without thinking. Most don’t need it. You learn the difference by trying a hard task without it and seeing where it breaks.

Subagents protect your main context

The Agent tool spawns a subagent that works in isolation. It has its own context window. When it finishes, you get a summary back, not the full transcript.

This matters because some operations bloat your main context badly. A large grep across the repo. Reading several files to find one piece of information. Web research with multiple page fetches. Big find commands that dump thousands of paths.

Delegating those to an Explore or general-purpose subagent keeps your main thread clean. You get the answer.

A couple of patterns that pay off here.

• Parallel subagents: if you have three independent questions, launch three subagents in one message. They run concurrently. Sequential launches are wasted time.
• Trust but verify: the agent’s summary is what it intended to do. If it claims it edited files, run git diff and check. Subagents will sometimes report success on a partial implementation. Treat the report as a hypothesis, not a fact.

Input shortcuts that change the workflow

Three small features most people miss.

! runs a shell command directly in the conversation. Output lands in context. Useful for interactive things you’d otherwise have to switch terminals for:

! gcloud auth login

! git log --oneline -20

The shell output becomes part of the conversation, so Claude can act on it immediately.

@path/to/file pulls the file into context inline. You don’t have to ask Claude to read it. Handy when referencing a specific file in your prompt:

Refactor @src/auth/session.ts to use the new token format from @src/auth/tokens.ts

# prefix quick-saves the line to a CLAUDE.md. It prompts you to pick which one (project, user, or local). Catch yourself repeating an instruction? Save it once.

# never edit files under generated/

# this project uses pnpm, not npm

These three together cut a huge amount of friction out of normal use.

The CLAUDE.md hierarchy

CLAUDE.md files auto-load as context every session. The hierarchy:

• ~/.claude/CLAUDE.md is user-level. Loads in every session everywhere.
• /CLAUDE.md loads in this project.
• /CLAUDE.md loads when you’re working inside that directory.

Use the hierarchy. Module-specific belongs in src/payments/CLAUDE.md, not the project root. Personal preferences (“I always want explanations in terms of TypeScript analogies”) belong in your user-level file, not committed to the repo.

The best use of CLAUDE.md is for the things you find yourself explaining twice. Example:

• Use the existing logger, don’t import a new one.
• Tests live in tests/, not next to the source.

Save it once, never explain it again.

Custom slash commands

If you paste the same prompt twice, make it a slash command. Drop a markdown file in .claude/commands/. Example:

.claude/commands/changelog.md

Generate a changelog for the commits since the last release tag. Group by feat / fix / chore. Include PR numbers where present.

Now /changelog runs that prompt. Commit .claude/commands/ to your repo, and your team gets them too.

A few worth having: /review for code review of pending changes, /explain to explain a file or function in plain English, /test to write tests for the current changes. You might also use skills, but command is the simplest form, use skills only when you need to run scripts.

Hooks for “always do X”

Memory and CLAUDE.md are read by Claude, not enforced by the harness. If you want a behavior that always happens, regardless of what Claude decides, that’s a hook.

Hooks live in settings.json and trigger on events:

• PreToolUse runs before a tool call. Can block it.
• PostToolUse runs after. Can react.
• Stop runs when Claude finishes a response.
• UserPromptSubmit runs when you submit a prompt.

What people actually do with them, for example:

• A Stop hook that runs npm run lint after every response.
• A PreToolUse hook that refuses any rm -rf outside /tmp.
• A PostToolUse hook that auto-formats edited files.

If you’ve ever told Claude “always run tests after editing” and it forgot two responses later, that’s a hooks problem, not a memory problem.

Switching models mid-session

/model swaps the model for the current conversation. Use it.

The common pattern is Opus for design, debugging, and the hard reasoning bits, then Sonnet for high-volume edits where speed matters more than depth. You don’t need Opus to update a hundred import paths.

Most people pick one model at session start and never switch. Matching the model to the phase of work is one of the easier wins available.

Worktrees for parallel work

Git worktrees let you check out multiple branches of the same repo into separate directories. With Claude Code, that means multiple sessions on different branches without stomping on each other.

git worktree add ../task-manager-feature-x feature-x

cd ../task-manager-feature-x

claude

Run a second claude from your main worktree on a different branch. Two sessions, two branches, one repo.

The Agent tool also accepts isolation: “worktree”, which sandboxes a subagent’s work in its own worktree. Useful when you want an agent to attempt a risky change without touching your working tree until you’ve reviewed it.

Prompt quality matters more than model choice

This is the most underrated thing about getting good output.

Compare:

• “Fix the session bug”
• “Fix the bug in src/auth/session.ts:142 where expiresAt is set in seconds but compared in ms”

The second one will get the right fix from any model. The first will get speculation, even from the smartest one. Two prompt patterns that work. Telling Claude what not to do is often higher leverage than telling it what to do:

Don’t refactor surrounding code, don’t add tests, don’t touch the migration. Only change the bug on line 142.

Without that, you’ll often get a “while I was in there” cleanup pass that adds noise to your diff. For exploratory questions, ask for a recommendation with the tradeoff, not a plan. “How should we approach X?” answered as a recommendation gets you a useful starting point. Answered as a plan, you get premature commitment to a path before you’ve decided it’s the right one.

Verify before claiming done

The most common failure mode is “should work” or “looks correct” without actually running it.

Type checks and unit tests verify code, not feature behavior. If you changed UI, open the browser. If you changed an endpoint, hit it. If you changed a script, run it.

When Claude reports a task as complete, the safe move is to ask what it actually ran to verify. If the answer is “I read the code”, that isn’t verification.

If you don’t want to remember all of this

AI DevKit is a Claude Code setup that bakes these patterns into skills and hooks. The right thing happens automatically, so you don’t have to remember.

A few of the skills line up directly with sections from this post.

The verify skill auto-triggers when Claude claims a task is done. It runs the verification step Claude was about to skip.

The dev-lifecycle skill walks a feature from idea to merged code: requirements, clarification, design review, TDD-style planning, implementation, tests, code review. At every phase, it forces you to spell out the goal, the constraints, and what done looks like before Claude writes anything. You can’t skip ahead with a half-formed plan.

The debug skill kicks in when you’re chasing a bug. It runs Claude through a real RCA: reproduce, isolate, hypothesize, then verify the fix.

The document-code skill documents code without your guiding function by function.

Beyond the skills, AI DevKit adds a few things to the harness.

A local memory service, for the long-term memory CLAUDE.md can’t do. CLAUDE.md is a static file you maintain. The memory service learns across sessions, so Claude stops making the same mistake twice in different conversations.

An orchestration layer for running multiple Claude Code in parallel. Worth it once you are trying to run many agents at the same time.

Telegram integration, so a long-running agent can ping you when it needs input or hits a blocker. Frees you from babysitting the terminal.

If my sharing resonates with you, subscribe to my blog. I share what I learn while building real systems with AI in the loop. You can also follow me on X or Threads for more thoughts and ongoing experiments.

Some people see it as a myth. Some people see it as a harmful label that creates hero culture. Some people have worked with engineers who clearly create much more impact than others, and believe the idea is real.

I sit somewhere in the middle.

I don’t think a 10x engineer means someone who writes 10x more code than everyone else. That version of the idea was never useful to me. Writing more code is not the same as creating more value. Sometimes, the best engineer is the one who removes code, simplifies the system, or prevents a problem from happening in the first place.

To me, a 10x engineer is someone who creates much higher impact than expected.

That impact comes from how they understand problems, how they recognize patterns, how they design systems, how they debug issues, and how they make decisions with simplicity in mind.

What’s changed

Now, AI changes the equation a little.

Not because AI magically turns every engineer into a 10x engineer. It does not. In some cases, it does the opposite. It helps people produce more code, more documents, more prototypes, and more noise without necessarily producing better outcomes.

What AI really changes is where leverage sits.

Before AI, a lot of engineering time was spent on manual implementation. Writing boilerplate. Searching the codebase. Creating test cases. Reading unfamiliar files. Updating similar patterns across different places.

AI can compress a lot of that work.

But when execution becomes cheaper, the bottleneck moves somewhere else. The harder part is no longer only writing the code. It is deciding what should be built, giving the right context, supervising the output, verifying correctness, and making sure the change is safe to ship.

That is where the new 10x engineer starts to look different.

A modern 10x engineer consistently turns ambiguous problems into safe, shippable outcomes with minimal coordination overhead, while using AI agents to compress execution time.

That sounds simple, but it is not easy.

Because AI does not remove the engineering discipline. It makes the lack of discipline more visible.

If the requirement is unclear, AI will still generate something. If the system context is missing, AI will still make assumptions. If tests are weak, AI-generated code can still look correct while quietly breaking behavior. If the engineer does not understand the domain, the output may feel convincing but be completely wrong.

Fundamentals matter more

Engineers still need to understand systems deeply enough to judge what AI produces. They need to understand architecture, data flow, API contracts, failure modes, testing, security, performance, and production behavior.

AI can help you move faster, but it cannot own the judgment for you.

This is the part I think many people underestimate. If you cannot review the code properly, AI does not make you senior. It only makes you faster at producing things you may not understand.

Context engineering

The new 10x engineer has a few traits that matter even more in an agentic organization.

The first one is context engineering.

Good engineers already know how to explain problems clearly to other humans. In the AI era, this becomes even more important because agents also depend on context.

A strong engineer can turn a messy idea into a clear problem statement. They document assumptions, constraints, edge cases, success criteria, and boundaries. They make the work understandable enough for both humans and AI agents to execute correctly.

Good context reduces back and forth. It reduces hallucination. It reduces rework. It makes execution more predictable.

Problem solving

The second trait is problem solving.

A high-impact engineer does not just take a ticket and ask AI to implement it. They clarify what problem we are solving. They break the work down. They understand the system impact. They think about blast radius. They decide what can be automated and what needs careful human review.

AI helps with execution, but the engineer still needs to direct the work.

Judgment

The third trait is judgment.

Good engineers know when to go fast and when to slow down.

Not every change deserves the same level of review. A copy update, a small UI tweak, a low-risk refactor, and a payment-related logic change should not go through the same mental model.

The AI era needs engineers who can adjust the level of control based on risk.

Move fast when the risk is low. Slow down when correctness matters. Add more verification when the blast radius is high. Keep humans in the loop where judgment is required.

Ownership

The fourth trait is ownership.

AI can generate code. AI can write tests. AI can summarize logs. AI can draft rollout plans. But AI does not carry production responsibility.

The engineer still owns the outcome. Testing is part of the work. Observability is part of the work. Rollout is part of the work. Debugging after release is part of the work.

A strong engineer does not say: “AI generated it”. That is not an excuse.

If you merge it, you own it.

Ambition

The fifth trait is ambition.

I don’t mean ambition as in chasing titles or trying to look busy. I mean the ambition to solve the problem properly.

A high-impact engineer does not stop at fixing symptoms. They ask why the issue happened. They look for the root cause. They remove repeated manual steps. They improve the system so the same class of problem is less likely to happen again.

This is where AI can create a lot of leverage.

The best engineers think in leverage

The best AI-fluent engineers I see do not only use AI to deliver features faster. They use AI to improve the way work gets done.

They improve the agent. They improve the prompt. They improve the documentation. They improve test coverage. They improve the workflow. They create reusable patterns so the next engineer and the next agent can move faster.

This is a different way of thinking.

In the past, work scaled mostly with people. If you wanted more output, you added more engineers. Of course, that also added coordination cost, onboarding cost, and communication overhead.

With AI agents, some types of work can scale differently.

Work starts to scale with the number of useful agents we can add and orchestrate. But that only works if the agents have enough context, enough guardrails, and enough verification.

This is why the 10x engineer in the AI era thinks in leverage. They don’t ask only, “How do I finish this task?”

They also ask:

• How do I make the next similar task easier?
• How do I make the agent better next time?
• How do I make this knowledge reusable?
• How do I reduce coordination for the team?
• How do I turn this solution into a multiplier?

Domain-agnostic engineering

This also changes how we think about domain ownership.

In the past, it was common for engineers to say, “This is not my domain”.

Sometimes that was reasonable. Systems were complex. Knowledge was scattered. Documentation was incomplete. The fastest path was to find the person who already knew the answer.

But with AI support, team agents, structured knowledge, and better context access, I expect engineers to become more domain-agnostic.

That does not mean every engineer becomes an expert in every system.

It means engineers should be able to contribute across codebases more often. They should be able to ask the agent to explain the flow, inspect the code, understand the patterns, identify risks, and propose a safe path.

When structured knowledge is accessible, “this is not my domain” becomes less acceptable as the default answer.

The better answer is:

“I don’t know this domain yet, but I can use the available context, inspect the system, and figure out a safe way to contribute.”

That is a very different mindset.

The environment matters

One thing I’ve learned over time is that engineers don’t become high-impact just by trying harder. The system they work in matters more than we like to admit.

In an agentic setup, that system is everything around them: repo structure, documentation quality, test coverage, CI speed, dependency graph, observability, and how easy it is to understand the system.

If these are messy, even strong engineers slow down. If these are clean, engineers can produce much better outcomes.

Creating more 10x outcomes is less about finding rare individuals. It is also about building an environment where good decisions are easier to make and bad ones are harder to ship.

That is a leadership responsibility as much as an individual responsibility.

Closing

The AI era does not remove the need for great engineers. It changes what greatness looks like.

The new 10x engineer is not a solo hero sitting in a corner producing ten times more code. It is the engineer who combines strong fundamentals, clear judgment, good context, agent orchestration, and deep ownership to create outcomes that scale beyond themselves.

AI gives us more leverage. But leverage is only useful when someone knows where to point it.

In the next post, I’ll go deeper into the practical habits engineers can build to create this kind of leverage with AI. If this perspective resonates with you, subscribe to my blog. I share what I learn while building real systems with AI in the loop. You can also follow me on X or Threads for more thoughts and ongoing experiments.

AI is becoming part of how we write, build, research, design, analyze, and operate. That is a good thing. I use AI heavily myself, and I believe it can meaningfully increase the leverage of individuals and teams.

But usage alone is not the goal.

A company can use AI everywhere and still become slower, noisier, and less disciplined. More generated documents, more prototypes, more code, more summaries, more dashboards, more activity, but not necessarily better outcomes.

That is the difference between AI adoption and AI maturity.

AI adoption means people are using AI.

AI maturity means AI is improving real outcomes.

The bar should not be “Did we use AI?”. The bar should be “What got better because we used AI?”.

• Did we reduce delivery cycle time without lowering quality?
• Did we reduce repetitive work?
• Did we improve product quality?
• Did we make better decisions?
• Did we lower the cost per unit of impact?
• Did we learn faster?
• Did customers or users feel the difference?

That is the part I care about.

AI maturity starts with problem clarity. Before using AI, we still need to understand what problem we are solving, who we are solving it for, and why it matters. If the problem is unclear, AI will only help us generate a faster version of the wrong thing.

This is one of the traps I see with AI demos. It is easy to generate something that looks impressive.

The second part is ownership.

AI can suggest, summarize, generate, refactor, test, and analyze. But AI cannot be accountable for the final decision. The person using AI still owns the thinking, trade-offs, quality, rollout, and outcome.

“My AI said so” is not a decision.

It is only an input.

The owner still needs to explain the reasoning. They still need to understand what was changed. They still need to know what could go wrong. They still need to own the result when it reaches users or production.

The third part is verification.

This is where speed becomes dangerous if we are not careful.

AI can help us move faster, but faster output without stronger verification creates hidden risk. In engineering, that means we still need tests, code review, observability, rollback plans, and clear acceptance criteria. In product work, that means user validation, quality review, success metrics, and business context.

AI output without verification is not acceleration.

It is risk moving faster.

The last part is reusability.

A one-off AI win is useful for learning. But mature AI usage should slowly turn into reusable workflows, tools, prompts, patterns, and knowledge. If every team keeps rediscovering the same prompt or building the same workflow from scratch, we are not really building maturity. We are just collecting scattered experiments.

That is where AI maturity starts to compound. A good workflow becomes a team habit. A good prompt becomes a shared pattern. A good automation removes repeated toil. A good agent workflow becomes part of how the team works.

To me, mature AI usage is not about replacing human judgment.

It makes human judgment more important.

As execution becomes cheaper, the bottleneck moves somewhere else. The hard part becomes choosing the right problem, giving the right context, reviewing the output, making the trade-off, and deciding what good actually looks like.

That is why I do not think the best AI-first teams will be the teams that generate the most output.

They will be the teams that turn AI into verified impact.

More speed, with ownership.

More output, with quality.

More automation, with judgment.

More ambition, without losing discipline.

That is the AI maturity bar I care about.

If this perspective resonates with you, subscribe to my blog. I share what I learn while building real systems with AI in the loop. You can also follow me on X or Threads for more thoughts and ongoing experiments.

I had reusable commands. I had predefined templates. I had a decent setup in Cursor and later Claude Code and Codex. It was enough to make AI generate code faster, help me plan, and reduce some repeated prompting. That was already a big step up from starting every session from scratch.

But after using it every day, I noticed that the biggest problem in my workflow was no longer code generation.

It was me.

I was still the one remembering what command to run next. I was still the one dragging context from one step to another. I was still the one making sure the AI did not skip verification, drift from the requirement, or quietly move too fast into implementation.

In other words, the AI could generate decent code, but I was still doing too much of the workflow orchestration myself.

That is the part that changed the most for me over the last six months while building and dogfooding AI DevKit.

I've believed for a while that AI-assisted development or Automatic Programming is the real future.

The engineer's workflow has fundamentally changed: code is now auto-generated at speed, so what matters most is sharp vision, deciding WHAT to build, fast proofs of concept, and… https://t.co/dmi6n65OCV

— Hoang Nguyen (@codeaholicguy) January 31, 2026

The old workflow: reusable, but still manual

Six months ago, my main idea was simple: make prompting more reusable.

Instead of rewriting the same long instructions again and again, I created reusable commands and predefined templates. That helped a lot. I could kick off requirement writing faster. I could structure planning better. I could avoid some of the prompt fatigue that happens when you keep repeating yourself in every new project.

It worked, but it still felt like a power user setup, not a real workflow system.

The commands were reusable, but they still needed me to manually invoke them at the right time. The templates were helpful, but they still depended on me to connect the dots between requirement, design, implementation, and review. If I was tired or moving too fast, the workflow could still become inconsistent.

The system was better than raw prompting but it just was not carrying enough of the burden yet.

What changed in the last six months

That is where the newer version of AI DevKit feels different.

The evolution was not just adding more commands. It was moving from commands and templates into skills, memory, auto-triggered behavior, and automatic verification.

That shift sounds small on paper. In daily use, it changed a lot.

• Skills made the workflow more reusable at the right level of abstraction. Instead of only saving a prompt, I could package a way of working.
• Memory helped the system carry forward context that I had already established before, so I did not need to keep restating the same engineering preferences or workflow rules.
• Auto skill triggering reduced the need for me to remember exactly when to push the next step.
• Auto verification made it harder for the process to silently skip the boring but important parts.

That is the real upgrade. My current workflow is better at carrying context, verifying work, and keeping me from repeating myself.

Recent development with AI DevKit

A recent feature in AI DevKit made that difference very obvious to me.

I was building interactive skill selection for ai-devkit skill add.

For the context, previously, if you wanted to add a skill with ai-devkit CLI, you needed to know the exact skill name. If you did not know what was available in a registry, you had to search first, then copy the name, then run the add command. It worked, but it was clunky. Two steps when one should be enough.

The feature itself was small. If the user runs ai-devkit skill add <registry> without a skill name, the CLI should show an interactive multi-select list so they can choose what to install.

I opened Codex and gave one sentence of instruction.

$dev-lifecycle new requirement: when user install skill ai-devkit s kill add <registry> but no skill name define, we will display an interactive selection for user to select the skill to install, the list of selection will be extract from the registry

From there, the dev-lifecycle skill took over and moved through the phases: requirement, review requirement, review design, execute plan, update planning, check implementation, write tests, and code review.

A few months ago, I could have built the same feature with reusable commands and templates. But I would still be the one manually stitching the process together. I would need to remember which command came next, decide when to review, decide when to verify, and keep the workflow aligned in my head.

Now the workflow itself carries more of that load.

The system pulled in a memory I had stored earlier about CLI commands needing a non-interactive fallback for CI environments. I did not have to remember that rule in the moment. It was already there. It became part of the requirement conversation automatically.

That sounds small, but this is exactly the kind of thing that gets lost in normal AI sessions.

Then it scaffolded requirement, design, and planning docs. It created the artifacts that support the code.

Then it reviewed its own requirement output. Then it reviewed the design against the requirement. Then, during implementation, it updated the planning progress as tasks were completed. Then it checked the implementation back against the requirement and design. Then it wrote tests against the requirement, not just against the implementation.

What feels more convenient now

The convenience is not only that the AI writes code for me.

The convenience is that I do not have to keep pushing the workflow forward manually.

• I do not have to remember every next move.
• I do not have to restate every important rule.
• I do not have to rely on discipline alone to make verification happen.

The workflow is becoming much better at carrying its own structure.

The whole session took under 30 mins from ideas to PR. For a feature that produced requirements, design, planning, implementation, verification, tests, and review artifacts, that still feels a bit wild to me. The artifact of this feature can be found on GitHub.

What still needs me

That does not mean it replaces judgment.

I still made product decisions during the implementation. I decided to keep the first version simple. I chose not to over-design the selection UI. I decided when a flat list was good enough for v1. The workflow drove the process, but I still drove the product and the tradeoffs.

I do not want AI to pretend to be a product engineer making judgment calls it does not understand. I want it to handle more of the repetitive engineering workflow around me so I can spend more time on the decisions that actually need me.

That is also why automatic verification matters so much.

Without verification, AI workflows feel productive right until they are not. The code looks ok. The output feels fast. Then later you realize the implementation drifted from the requirement, skipped an edge case, or quietly missed something obvious.

I have become more convinced that the real value in AI-assisted engineering is not just code generation. It is workflow discipline made easier to sustain.

That is what I have been trying to push AI DevKit toward over the last six months.

Try it yourself

If you want to test this workflow yourself, here is the easiest way to start.

The fastest way to get the full setup is with the engineer template, then run one command to install the dev-lifecycle skill, verify, tdd, debug, and everything else I use daily:

npx ai-devkit@latest init -t engineer.yaml

That engineer.yaml looks like this:

environments:
  - cursor
  - claude
  - codex
phases:
  - requirements
  - design
  - planning
  - implementation
  - testing
skills:
  - registry: codeaholicguy/ai-devkit
    skill: dev-lifecycle
  - registry: codeaholicguy/ai-devkit
    skill: debug
  - registry: codeaholicguy/ai-devkit
    skill: verify
  - registry: codeaholicguy/ai-devkit
    skill: tdd
  - registry: codeaholicguy/ai-devkit
    skill: memory
  - registry: codeaholicguy/ai-devkit
    skill: capture-knowledge
  - registry: codeaholicguy/ai-devkit
    skill: simplify-implementation
  - registry: codeaholicguy/ai-devkit
    skill: technical-writer

One command, all three agents (Claude Code, Codex, and Cursor) are configured, all skills installed.

Then open your favorite agent (Claude Code, Cursor, or Codex), then type: “Use dev-lifecycle skill to build [your feature].” Watch what happens.

The code is open source: github.com/codeaholicguy/ai-devkit

Docs: ai-devkit.com

Closing

Six months ago, I was mainly optimizing how to talk to the model better.

Now I care more about giving the model a workflow that can carry context forward, reuse proven skills, trigger the right behavior automatically, and verify work before I trust it too much.

A workflow system that stays useful across Cursor, Claude Code, Codex, and any other Coding Agent. Reduce the amount of repeated orchestration I need to do myself.

I still review the code and make the important decisions, and it is clearly better than where I started.

For me, that is the real evolution.

If your current AI workflow mostly helps you write code, but still makes you carry too much of the process in your head, that is exactly the gap I have been trying to close with AI DevKit.

If this perspective resonates with you, subscribe to my blog. I share what I learn while building real systems with AI in the loop. You can also follow me on X or Threads for more thoughts and ongoing experiments.

Back then, the conversation was about speed. Today, it is about discipline.

If you are still coding the same way you did two years ago, you are underperforming. Not because you are not capable. But because the leverage has moved.

AI did not just make us faster. It changed what matters.

I read AI news almost every day. Every day there is something new, new model, new benchmark, new workflow. I try not to overhype or overreact. But if I’m honest, there is a bit of panic inside me.

For the first time in my career, I see machines doing things that I spent my whole…

— Hoang Nguyen (@codeaholicguy) February 14, 2026

What changed in one year

One year ago, using Cursor or Claude Code already felt powerful. You describe a feature and get working code in minutes. That alone reshaped daily engineering work.

Today, multi-agent workflows are common. Structured reviews are expected. Running parallel agents in isolated worktrees no longer feels experimental.

You can let one agent draft a plan, another implement, and a third review. You can compare outputs from different models and choose deliberately instead of accepting the first answer.

In my day-to-day workflow with AI DevKit, I usually start by brainstorming with Claude Code using the /new-requirement command. Then I switch to Codex CLI to review both the requirement and the design through /review-requirement and through /review-design. Then, I move back to Claude Code for the implementation. It allows me to leverage the strengths of different tools and models, using each one where it performs best instead of forcing a single agent to handle everything.

I try to keep my agents busy. While I review the requirement with one agent, I let others handle implementation or review the design in parallel.

The tools evolved fast. But more importantly, the expectations evolved.

Speed is no longer the differentiator. Discipline is.

Engineer A vs Engineer B

Let me contrast two senior engineers.

Engineer A uses AI every day. He writes prompts, gets code, scans the diff, and merges. He is clearly faster than before. He ships more tickets per sprint. He feels productive.

Engineer B also uses AI every day. But his workflow looks different.

He starts from a helicopter view. The requirement is ambiguous at first. Instead of jumping to code, he lets the agent drive the clarification loop. He answers in chat. He pushes the agent to keep asking until edge cases, constraints, and trade-offs are explicit.

Engineer A edits the code directly when something looks off.

Engineer B communicates with the agent. He explains why it is wrong. He updates constraints. He adjusts the plan. He asks the agent to restate the decision before touching implementation. He treats the agent as a collaborator, not a code generator.

Engineer A trusts the output if it compiles and the happy path works.

Engineer B strengthens the tests. He asks the agent to generate a test suite, then adds edge cases around null inputs, boundary values, concurrency, and error handling. He forces the agent to explain why each test exists. He treats testing as the backbone, not a checkbox.

Both engineers are faster than they were two years ago.

This difference in behavior looks small. But it changes everything.

The discipline gap

AI amplifies your engineering discipline.

If your thinking is vague, AI produces vague structure at scale.

If your requirements are weak, AI generates confident but misaligned code.

If your review process is shallow, AI accelerates bugs.

The dangerous part is that both engineers think they are doing fine. Both are shipping. Both are faster than before. The difference only shows up months later.

The more I practice agentic workflows, the more I realize that testing becomes more important, not less.

When code generation becomes cheap, validation becomes the bottleneck.

In an agentic workflow, I recommend responding in chat. Let the agent drive the clarification loop. It will keep asking questions until the requirement is clear enough to move forward.

Requirements, design notes, and decisions are not documentation. They are execution inputs.

If the agent does something wrong, most of the time it is not about intelligence. It is about context.

Managing context is now part of the job.

Senior engineers must learn how to enrich context deliberately. And also how to keep it lean. Too little context creates mistakes. Too much context creates noise. Both require judgment.

From implementer to orchestrator

The role of a senior engineer quietly changed.

Before AI, your value often came from writing the hardest 500 lines in the system.

With AI, implementation cost drops. But the decision cost increases.

Now your value comes from defining the 50 lines that must never be wrong. The parts of the system where a small mistake creates long-term damage.

A senior engineer orchestrates both humans and machines.

You design the workflow. You define the phases. You decide when to branch into parallel agents. You decide when to compare multiple model outputs. You decide when to stop the agent and take over manually.

Multi-agent setups are powerful. You can run two models on the same task and pick the better solution. But this introduces cognitive load.

If you cannot clearly explain what each agent is responsible for, you are not orchestrating.

Context switching becomes a real skill. Energy management becomes part of engineering.

If you cannot hold the mental model of what each agent is doing and why, you lose control of the system.

The compounding effect

In the first month, the difference between Engineer A and Engineer B looks small.

Engineer A finishes a feature in one day. Engineer B also finishes in one day, maybe slightly slower because he invests in tests and structure.

After three months, Engineer B’s codebase is cleaner. Tests are stronger. Review loops are tighter. Decisions are documented as inputs, not afterthoughts.

After six months, Engineer B has reusable commands, templates, and structured phases. He can spin up new features with clarity. He can onboard agents faster. His feedback loops are consistent.

After twelve months, the gap compounds.

Engineer A is still faster than pre AI days. He can only focus on one problem at a time because his workflow is still single-threaded. He prompts, waits, reviews, merges, then moves to the next task. He was never trained to coordinate multiple agents running in parallel, so his output scales with his attention and hours, not with the number of agents he can control.

Engineer B is operating a system. He can scale the number of things he builds by increasing the number of agents he can clearly define, coordinate, and control.

The exponential effect does not come from typing speed. It comes from accumulated workflow leverage.

Why workflow must be portable

One more lesson I learned: do not couple your discipline to a single tool.

Cursor, Claude Code, Codex. They are interfaces. They will continue to evolve.

An orchestrator does not depend on one instrument.

If your process only works inside one UI, it is fragile. The moment the tool changes, your leverage resets.

Your workflow should be portable.

Structured phases. Reusable commands. Explicit review steps. Clear testing loops. Configurations that can move across environments.

Wherever the agent runs, your discipline should follow.

On your local machine. On a different laptop. On a teammate’s machine. Inside a CI pipeline. On a remote server. On the cloud.

This is one of the reasons I built AI DevKit. Not to lock into one model. But to standardize how I work with any agent.

The tool matters less than the workflow.

The uncomfortable truth

If you are still using AI as autocomplete, you are slowly left behind.

If you treat the agent as a faster junior engineer without redesigning your process, you are leaving leverage on the table.

Last year was about discovering speed.

This year is about building discipline.

Agentic engineering is not about clever prompts. It is about workflow design. It is about context management. It is about structured review. It is about testing as a first class citizen.

It is orchestration.

Rethink your workflow. Upgrade it.

Speed was only the beginning.

If this perspective resonates with you, subscribe to my blog. I share what I learn while building real systems with AI in the loop. You can also follow me on X or Threads for more thoughts and ongoing experiments.

After using Cursor, Claude Code, and other AI coding agents daily for a long time, I changed my mind.

When a capable model feels dumb, the problem is often not intelligence. It is context, what you gave it, what you did not, and what quietly fell out of the window.

This post is my experience with tokens and context windows, plus techniques to keep AI coding agents stable when tasks get long.

Tokens and context windows

A token is just a chunk of text that the model (such as Claude Opus or GPT Codex) processes.

• Sometimes it is a whole word.
• Sometimes it is part of a word.
• Sometimes it is punctuation.

There are some good, detailed explanations on the internet, so I won’t deep dive into how the tokenizer works. You do not need to know the exact tokenization rules. What matters is that everything becomes tokens in the end: code, comments, logs, chat messages, etc.

You also do not need to count them, but you do need to understand relative cost, for example:

• A short chat message is cheap.
• A function or interface is moderate.
• A full file is expensive.
• A long stack trace or repeated logs are very expensive.

The context window is the maximum number of tokens the model can hold in its head at the same time.

Just a simple illustration for understanding how context window affect your ChatGPT conversation. https://t.co/Aqqwx1d7p8 pic.twitter.com/51IUOHbIb6

— Hoang Nguyen (@codeaholicguy) August 11, 2025

If you imagine the model as reading from left to right, the context window is the size of the table it can spread papers on. Once the table is full, new papers push old ones off the edge.

When something falls off the table, the model does not partially remember it. It is simply gone. From that point on, the model can only guess based on patterns it has seen before.

This is why agents can feel sharp at the beginning of a task and unreliable later. It is not that they get tired. It is that the table gets crowded.

The failures you keep seeing

These failures look different, but they usually share the same root cause: context pressure.

Forget

The agent stops following a rule you stated earlier.

Examples:

• You said do not change API shape and it changes it anyway.
• You said use existing error types and it invents new ones.

What is actually happening under the hood:

Early in the session, your constraint competes with very little. It has strong weight in attention. As the session grows, more tokens arrive, such as diffs, logs, partial refactors, explanations. The original constraint is still technically present, but it is now one small signal inside a much larger pool of text.

Even before the hard window limit is reached, attention dilution happens. The model “sees” the rule, but it no longer treats it as central.

Drift

The agent starts solving a different problem than the one you are solving.

Examples:

• It starts refactoring style instead of finishing the feature.
• It optimizes performance when correctness is not done.

What is actually happening under the hood:

Language models are next-token predictors. They optimize for locally coherent continuations. If the most recent context heavily features refactoring, performance discussion, or style comments, the model will naturally continue along that trajectory.

Drift is often a local optimum problem. The short-term pattern in context overpowers the long-term goal.

Hallucinate

The agent claims things exist that do not exist.

Examples:

• Referencing functions that are close but wrong.
• Claiming files were modified when they were not.

What is actually happening under the hood:

When grounding context is incomplete, the model does not return “I do not know” by default. It fills the gap with the most statistically plausible continuation. If you showed it a similar function earlier, it may reconstruct a nearby variant. If you mentioned a file pattern, it may assume another file exists.

This is not malicious behavior. It is pattern completion under uncertainty.

Why this happens more in coding

Coding work has high dependency density.

In normal chat, if one sentence is slightly wrong, the conversation still flows. In code, one missing import breaks compilation. One wrong assumption about a type breaks behavior. One renamed field silently corrupts data.

Coding agents juggle multiple representations simultaneously: source code, diffs, chat, logs, etc. Each of these is token-heavy. More importantly, they have different semantic roles.

When all of them are mixed in a long session, the signal-to-noise ratio drops. The model is not just reading text. It is trying to reconcile structure, behavior, and history at the same time. Even before hitting the hard context limit, attention gets fragmented. The agent may technically “see” the goal, but its attention is pulled toward the most recent diff or the loudest stack trace.

This is why long coding sessions degrade faster than normal chat. It is a challenging problem, and Codex or Cursor shared that their focus is improving the long coding session.

Techniques that actually keep agents stable

I think about context in three layers.

• Layer 1: the contract
  • This must never be lost.
  • This includes goals and non-goals, constraints, acceptance criteria, invariants that must hold.
• Layer 2: the working set
  • The minimum needed for the current step.
  • This includes the files you are editing, the interfaces it depends on.
• Layer 3: the noise
  • This is everything else.
  • This includes old attempts, long logs, unrelated files added just in case.

I will try to optimize the context to reduce the noise as much as I can, while keeping the contract as simple as I can.

Start with a written contract

I do it even if it feels redundant. A contract is not for the model. It is for stabilizing attention.

My hypothesis is that attention is relative. The model weighs tokens against each other. A concise contract placed at the top of the prompt anchors the distribution of attention. It keeps global intent visible even when local diffs and logs get noisy.

When drift happens, do not argue inside a polluted context. I will restate the contract cleanly and continue. If needed, restart with the contract at the top.

Chunk by intent, not by files

I do not run one giant session until done.

I will split by intent, this concept is applied exactly in how I built AI DevKit, with phase splitting.

• understand requirement
• design approach and plan
• implement minimal slice
• add tests
• polish

Each chunk gets its own small working set and its own definition of done.

Large sessions fail because they mix planning, execution, debugging, and optimization in one attention pool. By chunking by intent, you reduce cognitive load for the model. Each phase has a narrower objective and fewer competing signals.

Convert history into state

When a session gets long, I will pause and ask the agent to produce a state snapshot:

• what changed
• what is broken
• what is next
• what constraints still apply

Then, I will start a new thread with:

• the minimal files for the next step
• the contract
• the snapshot

Context compaction is an item in AI DevKit roadmap, and I hope that I can release it soon.

Treat rules as context compression

Rules exist so you do not repeat yourself.

They should encode stable invariants:

• naming conventions
• architectural boundaries
• error handling patterns
• preferred libraries
• etc

Good rules are small, stable, encode conventions and invariants.

Bad rules are long, include task-specific details, change every session.

You can also leverage files like AGENTS.md or CLAUDE.md as stable instruction anchors.

Instead of repeating architectural principles, coding conventions, and workflow rules in every session, move them into a dedicated, version-controlled instruction file. These files act as persistent context contracts that the agent can load explicitly when needed.

Design tool outputs for context efficiency

Tool outputs still consume tokens, so I will prefer:

• structured data over text
• summaries over raw logs

This is also why I personally prefer CLI-style integrations over heavy MCP-style preload patterns for many workflows.

When you preload large tool responses into the conversation, you are paying the context cost upfront. The agent must carry that entire payload in its active window, even if it only needs a small portion of it.

A CLI model is different. The agent calls a command when it needs something. The command returns structured output to stdout. The agent consumes exactly what is required for the current step.

This is the spirit behind how I designed AI DevKit memory. Memory is not preloaded into every session. It is a standalone CLI. The agent calls it when needed, gets structured, minimal output, and continues reasoning.

Use multi-agent workflows deliberately

Multi-agent setups multiply context consumption and coordination cost. You are not just paying in tokens. You are paying for reconciliation complexity.

Use parallel agents when uncertainty is high, and you want alternative approaches. For deterministic execution, a single agent with a stable context stack is usually more reliable.

For example, once the plan is stable and the acceptance criteria are clear, I prefer one agent to execute end-to-end.

I do not split separate agents for backend, frontend, etc that stage. That kind of split increases coordination overhead and context duplication. Each agent needs a slightly different slice of the same contract, the same files, the same invariants. You end up paying the context cost multiple times and then reconciling their outputs.

Instead, I keep a single focused agent with a clean contract and a tight working set. It holds the intent consistently from implementation to tests to small refactors.

I only split agents when the problem space itself is separable. For example, different features that do not share tight coupling, or alternative solution explorations where diversity of approach is valuable.

Closing thought

AI tools made generation cheap.

They made information selection expensive.

When the agent feels dumb, do this

1. Pause and assume context loss first.
2. Restate the contract.
3. Reduce the working set.
4. Ask for a state snapshot.
5. Continue in a fresh thread.

If you learn to manage context deliberately, your agent will feel stable and consistent. Not because the model changed, but because your workflow did.

If you want to read more about software engineering in the AI era, subscribe to my blog. I will keep sharing what I learn while building systems with AI in the loop.

Every few weeks, there is something new. Agents, rules, skills, sub-agents, MCP, hooks. Each introduces its own vocabulary, and most explanations jump straight into features without explaining why any of these concepts exist in the first place.

So you try them. Some things feel powerful. Some feel magical for a moment. Then the setup starts to feel fragile and hard to reason about.

The problem is not that these concepts are bad. The problem is that they are rarely taught as parts of a system.

I went through the same confusion. The goal of this post is to give you a mental model you can apply regardless of the tool, so you know when a concept matters and when it is just noise.

The core mental model

An AI coding agent repeatedly does this:

1. Read persistent context
2. Interpret intent
3. Plan an approach
4. Generate or modify code
5. Optionally observe results
6. Iterate

Every concept exists to control one specific step in this loop.

• Rules provide constraints.
• Commands initiate execution.
• Skills guide methodology selection.
• Sub-agents limit responsibility.
• MCP enables external interaction.
• Hooks enforce guarantees.

If two concepts try to control the same step, confusion follows.

Rules

Rules exist to separate constraints from execution. Without this separation, engineers keep encoding constraints inside prompts, and the agent’s behavior becomes unstable as soon as tasks change.

They are consulted by the model whenever it approaches a task, regardless of what the task is.

What it is in practice

Rules are persistent constraints that apply across all agent interactions, usually written as Markdown text.

They describe what must always be true, regardless of the task being executed. Rules live outside individual requests and do not change from task to task.

In practice, rules define boundaries rather than actions.

What it is good for

Rules are good for enforcing invariants.

They protect things you do not want the agent to renegotiate every time:

• architectural boundaries
• dependency choices
• folder structure
• coding/testing conventions
• backward compatibility expectations

Once something is an invariant, it belongs in rules.

Example

To keep this grounded, we will use one example throughout.

You already have a Task API in production. Yesterday, you used an AI agent to add a new endpoint. Today, you want to add more features.

Two constraints matter:

• Existing behavior must not change.
• Tests must keep passing.

For the Task API, useful rules look like this:

• Validation logic must live in the domain layer
• No new dependencies may be introduced
• Existing test helpers must be reused
• Public API behavior must not change without explicit instruction

With these rules in place, prompts can stay short and focused on intent because constraints are no longer embedded inside them.

Common misunderstanding

The most common mistake is treating rules as behavioral coaching.

Rules like:

• Write clean code
• Think carefully before coding
• Refactor when appropriate

do not define constraints. They force interpretation.

If a rule requires judgment to apply, it does not belong in rules. It belongs in a skill or in human review.

Commands

Commands exist to express execution intent. Unlike skills, which define how a class of problems should be solved, commands describe what specific action the agent should perform right now. They answer the question: what should the agent do now?

They are invoked explicitly by you and tell the model what task to execute now.

What it is in practice

A command is a named or explicit instruction, typically stored as Markdown or plain text, sometimes with parameters.

Commands are scoped to a single action and executed in the current context.

What it is good for

Commands are good for:

• executing a specific change
• triggering a known workflow
• keeping interaction fast and direct

They work best when the intent is clear.

Example

Examples of commands are

• add input validation
• update tests
• create a new entity

Commands should not describe architecture, style, or process. That belongs elsewhere.

Common misunderstanding

Commands are often overloaded with policy.

Long commands that explain how to structure code, where logic lives, and what tradeoffs to consider are compensating for missing rules or skills.

When commands get longer over time, it is a signal that execution is no longer the only problem.

Skills

Skills exist to separate methodology from execution. They capture how you solve a recurring class of problems.

They are consulted when the model recognizes a task as belonging to a known category.

What it is in practice

A skill is a reusable instruction set that teaches the agent a specific way of working. It is a bundle of instructions plus optional tools, usually defined as Markdown plus scripts or tool bindings.

It is not a one-off request. It is a repeatable method.

What it is good for

Skills are good for:

• capturing repeatable engineering patterns
• reducing prompt repetition
• improving consistency across tasks
• encoding domain-specific practices once and reusing them everywhere
• executing tools or scripts as part of a known method

They remove methodology from commands and keep commands focused on intent.

Example

A validation skill might encode:

• how schemas are structured
• how errors are returned
• which edge cases must be tested

When adding validation, the model applies this skill during execution.

Common misunderstanding

Skills are often created too early.

If something does not repeat, it does not deserve a skill.

Sub-agents

Sub-agents limit who is allowed to act on a task by explicitly constraining scope, context, and responsibility.

They exist to prevent a single agent from making broad, cross-cutting changes when the task itself only requires a narrow, well-defined area of action.

They are invoked when work is delegated instead of executed directly.

What it is in practice

A sub-agent is a scoped agent with a specific responsibility and limited context, usually expressed as Markdown with structured metadata.

The main agent decides when to delegate and what authority the sub-agent has.

What it is good for

Sub-agents are good for:

• controlling blast radius
• separating concerns
• preventing unintended cross-changes

They reduce risk by narrowing responsibility.

Example

• Sub-agent A modifies validation logic only
• Sub-agent B updates tests only

Each sub-agent executes within its scope.

Common misunderstanding

Sub-agents are often framed as parallelism.

You rarely introduce sub-agents because you want things to run faster. You introduce them because a single agent handling too many responsibilities becomes unpredictable.

Their real value is containment: limiting what can change, where it can change, and why. Speed is a side effect at best, not the goal.

MCP

I have a separate, longer post about MCP. Please check it out.

Basically, it is invoked when the model needs real-world feedback instead of guessing. It also allows the agent to interact with systems.

What it is in practice

MCP connects the agent to tools, environments, or data sources.

The model calls MCP tools to observe outcomes it cannot infer from text alone.

What it is good for

MCP is useful for:

• validating assumptions
• running tests
• reading failure output
• querying external systems

Example

• running the external test suite after changes
• inspecting failing test output
• interact with the browser for testing
• query data from the database

Common misunderstanding

MCP is often treated as intelligence.

It does not improve reasoning. It improves feedback.

Hooks

Hooks exist to separate enforcement from reasoning. They run outside the LLM reasoning loop and are triggered regardless of what the model decides.

They guarantee that something always happens.

What it is in practice

A hook is a deterministic action triggered at a specific point in the workflow.

What it is good for

Hooks are good for:

• enforcing policies
• running tests
• formatting code
• blocking unsafe changes

Example

• run unit tests after file changes
• block edits to protected directories

Common misunderstanding

Hooks are sometimes used to encode decision logic.

If a hook needs reasoning, it belongs in a skill or sub-agent instead.

How this fits together

A stable setup looks like this:

• rules define constraints
• commands express intent
• skills capture repeated methodology
• sub-agents control scope
• MCP enables observation
• hooks enforce guarantees

You do not start with all of this.

Each layer exists because a specific problem appears.

A starter kit for working with AI Coding Agents

Once you understand the concepts above, a new problem usually appears.

You now know what rules, commands, skills, sub-agents, MCP, and hooks are for, but setting them up across different tools still takes time and cognitive energy. Each tool such as Cursor, Claude Code, Antigavity, Codex, OpenCode, etc has its own conventions, file locations, and wiring. The concepts are the same, but the setup friction is real.

This is the gap AI DevKit is designed to close.

AI DevKit is a starter kit for engineers who want to work with any AI coding agent in a structured way, without rebuilding the same scaffolding every time. It gives you a ready-to-run foundation so you can focus on building software, not on repeatedly re-learning how to wire agent workflows.

You still decide the rules. You still design the skills. You still own the system. AI DevKit simply removes the accidental complexity so you can start from a sane baseline instead of a blank slate.

AI DevKit is open source, and contributions are welcome from engineers who want to shape how practical AI agent workflows should look.

Closing

Coding AI agents are not assistants. They are execution systems with explicit control layers.

They do not decide what is important, what is safe, or what should change. They execute within the structure you give them, and they fail in predictable ways when that structure is missing.

Once you understand when each layer is consulted and what form it takes, new tools stop feeling overwhelming and start feeling composable. The agent ultimately reflects your system design decisions, not your intent, and responsibility for correctness, safety, and clarity still sits with you as the engineer.

If you want to read more about software engineering in the AI era, subscribe to my blog. I will keep sharing what I learn while building systems with AI in the loop.

I made a rule for myself. I would use AI DevKit to build the features inside AI DevKit. If the workflow breaks, the product is not ready.

About AI DevKit:

If you have not seen AI DevKit before, think of it as a way to work with AI without giving up control. Instead of treating AI as a black box that generate code, AI DevKit forces clear intent, explicit constraints, and tight feedback loops, so AI can execute well-defined work while humans stay responsible for direction and decisions. It can work well with any AI Coding Agents that you like, such as Cursor, Claude Code, Codex, Antigavity, OpenCode, etc.

This post is a build log of that experience, and what it taught me about where AI helps and where humans still need to steer.

My goal is to turn AI DevKit into a tool that makes building with AI more effective through clearer intent and sharper inputs. By reducing the amount of steering engineers need to do, we can progressively hand off execution to AI, while humans stay focused on deciding what to build and defining the right constraints.

The problem I was trying to solve

Every time I asked an agent to implement something, I retyped the same rules:

• Always return Response DTOs for APIs.
• Validate input at the boundary.
• Follow our folder structure.
• Avoid introducing new libraries without a reason.

I could paste these into prompts, or even add them as rules, but neither felt right.

Rules tend to trigger only in very specific contexts, often tied to certain files or patterns. You cannot realistically cover every case that way. Adding more rules also does not scale well. It increases complexity and still leaves gaps.

Some of these rules are also personal preferences. They make sense for how I work, but I would not want to enforce them at a project level. Others are not really rules at all. They are knowledge about the product, its constraints, or the tradeoffs we have already made.

Prompts and rules both fall short here. Prompts are ephemeral and disappear after each task. Rules are rigid and incomplete. Neither is a good place to store evolving engineering knowledge that needs judgment and context.

What I wanted was much more mechanical:

• store small, precise rules once
• retrieve them automatically when relevant
• apply them consistently across tasks

Not memory as chat history. Memory as engineering guidelines that actually get used.

That framing did not come from AI. It came from me being annoyed at repeating myself.

First assumption: memory is just storage and retrieval

At the beginning, I thought the feature would be straightforward.

1. store something
2. search it later
3. inject it into context

But once I started writing the requirements, I hit the first hard question.

What exactly are we storing?

If I store everything, retrieval becomes noisy. If I store long explanations, context gets polluted. If I store vague advice, the agent behaves vaguely.

This is where human steering mattered.

The agent was very good at expanding the scope. Chat history, flexible memory, richer schemas, future extensibility. All of it sounded reasonable.

But it did not answer the real question I had while working: What do I actually want the agent to remember while I am coding?

So I forced an explicit model:

• each memory item is one actionable rule
• short title
• content with rationale and optional examples
• tags and scope to guide retrieval

That was the moment where dogfooding mattered. I was not designing for a theoretical “memory feature”. I was designing for what I personally wanted the agent to recall in the middle of real work.

Second assumption: smarter retrieval is better

Once the memory model was clear, retrieval was the next decision.

The obvious modern answer these days is embeddings. The agent suggested it. It made sense technically.

But I kept asking a different question.

When a rule is retrieved, how do I know why it appeared?

If the system cannot explain itself, I cannot trust it. And if I cannot trust it, I will stop using it.

So I deliberately chose determinism over cleverness:

• SQLite with FTS5
• BM25 as the primary ranking signal
• title weighted higher than content
• predictable boosts from tags and scope

This was a tradeoff.

I accepted that lexical search is not as “smart” as embeddings. But I gained something more important for this product stage: repeatability. If I run the same query tomorrow, I want similar results. That is how you build trust in a tool that runs inside your development loop.

That judgment does not come from prompts. It comes from knowing how it feels to work inside a tool every day.

Using the tool exposed quality problems

Once I started “using the memory service while building the memory service”, problems showed up.

The biggest one was quality.

If you let vague knowledge in, the agent pulls it out later and behaves vaguely. If you let duplicate rules in, ranking gets worse, and context gets messy.

So I moved quality checks to write time:

• knowledge must be specific and actionable
• generic advice is rejected
• deduplication by normalized title and scope
• deduplication by content hash
• strict content length limits

This is boring engineering work. But it is the difference between “a memory feature exists” and “memory actually helps”.

AI will happily generate more. Humans need to decide what is allowed.

Some problems only appear when a human is in the loop

A good example is the MCP inspector breaking because dev scripts printed logs to stdout.

From a technical perspective, nothing was wrong. The code worked. The server ran. From a usage perspective, the tool was broken.

The agent could not tell me this mattered. It could help debug it once I pointed it out, but it did not experience the failure.

Another example was integration tests failing because the SQLite connection was shared globally. The agent helped write the tests, but it did not anticipate how the global state would behave once everything was wired together.

Fixing this required stepping back, understanding how the system would actually be used, and redesigning test isolation. This was not about making the code more correct. It was about making the system safe to depend on. And it is the human responsibility.

This is a recurring pattern with AI-assisted development. AI helps you move faster once you see the problem. But a human still needs to notice what actually feels broken.

What this build changed in how I think about AI tools

My thoughts about AI tools stay the same, since the day I wrote “AI changes the Tools, you still own the Craft“:

The best engineers of the future won’t just know how to use AI, they’ll know when not to.

So, as this era unfolds, don’t fear the tools. Learn them. Use them. Stretch them. Break them. But never forget: It’s your thinking, your judgment, your care that turns software into something worth shipping.

The craft is still yours. Own it.

By the end, the memory feature looked very different from my initial idea.

It was smaller, stricter, and more boring. There is no fancy tech that was applied.

This build reinforced something I strongly believe.

AI can accelerate implementation. It cannot define intent, constraints, or quality on its own.

Humans still need to steer:

• what should exist
• what should be rejected
• which tradeoffs matter
• when predictability beats capability

Using AI DevKit to build AI DevKit features forced that discipline. It exposed assumptions I did not know I had. It turned fuzzy ideas into concrete constraints.

That is why I like dogfooding. It does not validate your ideas. It challenges them until they become real.

AI DevKit is open source. If this way of working with AI resonates with you, contributions, experiments, and critical feedback are very welcome.

If you want to read more about software engineering in the AI era, subscribe to my blog. I will keep sharing what I learn while building systems with AI in the loop.

As an engineer using both Cursor and Claude Code daily, I see no significant difference in the quality of code produced, the model output quality is mostly determined by how clearly and structured you plan + describe the task.

The one clear, practical advantage I observe with…

— Hoang Nguyen (@codeaholicguy) December 30, 2025

After using both tools daily, I think that question misses the point.

I don’t see a meaningful difference in code quality between Cursor and Claude Code anymore. Once you reach a certain baseline, the output quality is mostly determined by how clearly and structurally you plan the task, not which tool you use.

This post focuses more on my real-world experience. No benchmarks. No feature matrix. Just how these tools actually feel in real engineering work, as of today.

The real difference is the workflow shape

Here is the first thing I noticed over time.

• When the task is vague, both tools produce vague solutions.
• When the task is structured, scoped, and explicit about constraints, both produce solid, reviewable code.

I used to believe one tool was “smarter”; I thought Claude Code may be better because Anthropic owns it, and they know how to unlock the full potential of the model. That belief did not survive long.

Planning, decomposition, and clarity dominate everything else. The tool mostly amplifies whatever state you are already in.

Where the difference starts to show is not intelligence, but workflow shape.

• Claude Code nudges me toward exploration.
• Cursor nudges me toward convergence.

That difference sounds subtle, but it becomes very obvious once you feel it day after day.

When many things need to move at once

There is one mode where Claude Code consistently feels more natural to me: when I want to run multiple things in parallel.

This includes:

• Spawning several agents to explore different approaches
• Running independent sub-tasks at the same time
• Delegating background work that does not need constant supervision
• Letting work progress asynchronously while I focus elsewhere

This happens early in a project, but it also happens later. The key is not timing, but parallelism.

Claude Code shines when work can be decomposed and executed concurrently. The CLI and agent-first model makes it easy to treat AI as background workers, not just an interactive assistant. Exploration, testing, refactors, and well-scoped bug fixes all fit naturally here.

When understanding and control matter

There is another mode where Cursor consistently feels more friendly: when I need to slow down and focus.

If you ask me whether I would still choose Cursor without its AI features, the answer is no. If I do not need AI at all, I would go back to my favorite editor, Neovim, and review or edit the code myself. In this discussion, though, we are specifically talking about AI-powered editors. In that context, for this stage of the workflow, my preference is Cursor.

Whenever I need:

• Deep understanding of the codebase
• Reviewing plans or generated changes
• Diffing between versions
• Explaining context to myself
• Reading code carefully
• Navigating files, symbols, and relationships

Cursor feels better.

This can happen early or late in the lifecycle. Planning, design, and core implementation often fall into this category, even though they happen before implementation is complete. I want tight feedback loops, strong context, and deep visibility into the codebase.

Cursor helps me stay grounded. It is better suited for careful inspection, sense-making, and deliberate change.

It is parallel vs focus

With this framing, the pattern becomes clearer.

Some work benefits from parallelism. Some work benefits from focus.

Claude Code fits naturally when many things need to move at once. Cursor fits naturally when I need to slow down and understand.

Neither is objectively better. They are optimized for different modes of work, not different points on a timeline.

Why I built AI DevKit

This way of thinking is also the motivation behind why I built AI DevKit.

As I started using both Cursor and Claude Code across different phases, I realized the real problem was not switching tools. The problem was losing structure and context when switching.

Planning lived in one place. Implementation lived in another. Testing and bug fixes lived somewhere else. Every pause or context switch added friction, not because of the tools, but because the work itself was not structured clearly enough.

AI DevKit is my attempt to solve that at a workflow level.

I treat software work as a set of explicit phases: planning, design, implementation, review, testing, and bug fixing. Each phase benefits from different levels of human attention and different tools.

Planning, design, and core implementation still need a lot of deliberate thinking from me. This is where I want strong context, tight feedback loops, and deep visibility into the codebase.

Testing, validation, and many bug fixes are different. Once intent is clear, these tasks are more mechanical. In those phases, I am often comfortable delegating almost fully to background AI execution. Claude Code feels stronger there today, especially when I can spin up focused tasks in your terminal and let them run asynchronously while I work on something else (I will talk more about how I set up my terminal to orchestrate different Claude Code processes in another post). This is where velocity really improves. With a clear plan, we can let multiple tasks run in parallel instead of doing everything sequentially. The harder part is not execution, but managing context switching. As engineers, we need to deliberately design our workflows, documentation, and handoffs so we can move between tasks and tools without losing intent or quality.

This is only my perspective. Different engineers will draw the line differently. Some prefer to stay hands-on everywhere. Some trust AI much earlier. There is no single correct split.

What AI DevKit gives me is a structured, portable context. Plans, constraints, assumptions, and decisions are written down in a way that can travel across tools. I can pause a task in one environment, pick it up in another, and still know exactly which phase I am in and what I am trying to achieve.

Once that structure exists, tool choice becomes simple. I just ask one question: which phase am I in right now? The answer usually tells me which tool fits best.

Why CLI-first tools matter for the future

There is one more angle that is worth calling out explicitly.

Personally, I think many top AI companies are pushing CLI-first experiences for a reason. It is not about power users or nostalgia. It is about integration.

Personally, I think top AI companies are pushing for CLI because they want to push for more integration where coding agents are integrated in CI/CD pipeline so some of the engineering workflows can be delegated to AI in background.

— Hoang Nguyen (@codeaholicguy) August 16, 2025

CLI makes it much easier to integrate coding agents directly into CI/CD pipelines. Once you cross that boundary, AI is no longer just an interactive assistant sitting next to you. It becomes something that can run in the background, triggered by events, delegated work, and operate without blocking a human.

That shift changes how engineering workflows scale.

This is already happening for us at ShopBack. We are pushing very hard on running Claude Code inside our CI/CD pipelines to do real work for us. It is effective in specific areas.

For example:

• Running targeted code changes with clear constraints
• Delegating the inquiry support or issue tracing
• Fixing well-scoped bugs with reproducible steps

These are workflows where intent is already clear and the work is largely mechanical. Claude Code fits naturally here because it can run asynchronously, without UI friction, and without waiting for a human to sit in front of an editor.

This is a real advantage compared to Cursor.

Cursor shines when a human is actively involved. It is excellent for thinking, reviewing, navigating diffs, and shaping changes interactively. But it is not designed to own an execution environment in the cloud, check out code, read internal documents, and run as part of a pipeline without a human in the loop.

With Claude Code, we can own the environment. The agent can check out the repository, read documentation, apply changes, run validations, and report results, all inside infrastructure we control. There is no need to expose the codebase to another hosted editor or hook it into a separate cloud service just to make that possible.

That distinction matters once you start delegating work fully to AI in the background.

This does not mean everything should be automated. It does not mean engineers disappear. It means some parts of the workflow move out of the interactive loop entirely.

And that brings us back to phases again.

Early thinking, planning, and core design still demand human focus and tight feedback loops. Later, well-defined execution steps can increasingly be pushed into background agents running in CI/CD. Claude Code’s CLI-first nature makes that transition much easier today.

Again, this is not a universal truth. It is based on what we are seeing work in practice right now. Different teams and constraints will lead to different choices.

Stop asking which tool is better

I also see many engineers trying to standardize on a single “best” tool.

For individual engineers, I think that instinct is often wrong.

The more useful question is not which tool is better, but what you are doing right now.

• If you are thinking, exploring, and decomposing, tools that support parallel reasoning will feel faster.
• If you are reviewing, validating, and refining, tools that keep you grounded in the codebase will feel safer.

Strong engineers adapt tools to the phase instead of forcing the phase to fit the tool.

A note on time context

One last note on time context.

This is a snapshot of the current state. Both tools are evolving fast. Agent orchestration, context handling, and review workflows will keep changing. Some of these differences may narrow or even flip.

The durable insight is not which tool wins today. It is understanding why certain workflows feel better in certain environments.

Final takeaway

My personal takeaway is simple.

I do not force a full switch. I do not pick sides. I use the tool that fits the moment.

As long as I plan clearly and stay deliberate, both tools deliver more than enough. The real leverage comes from how I think, not which button I press.

If you feel torn between Cursor and Claude Code, you are probably asking the wrong question.

If you want to read more about software engineering in the AI era, subscribe to my blog. I will keep sharing what I learn while building systems with AI in the loop.

You wrote a few sentences, pasted them into a chat box, tweaked the wording, and moved on. If the output was not good, you tried again. Nothing else depended on it. The cost of getting it wrong was close to zero.

That phase did not last long. In The Turning Point of AI, I shared that:

AI isn’t just a tool for completing your sentences or suggesting the next line of code. We need to see it as a new way of building software.

The moment prompts moved out of chat windows and into those systems, their role changed. They were no longer throwaway text. They were reused across flows. They carried logic. They returned structured data that other parts of the system depended on.

At that point, prompts quietly became part of the system.

But the way we wrote them did not change. They were still plain text strings. Easy to write. Easy to paste. Easy to grow in the wrong direction.

Prompts as plain text, and the pain points

At first, this felt fine. A prompt was just a template string. Some variables. Maybe a bit of interpolation. It looked simple enough, and it worked for small use cases.

Pressure 1: reuse

The first pressure came from reuse.

The same prompt started powering multiple features. Copy-paste became the default strategy. Someone copied it to make a small change. Someone else added another instruction for a different flow. Over time, the prompt logic drifted.

No one could confidently say which parts were shared, which parts were safe to change, and which parts would break something else. Ownership of the structure slowly disappeared.

Nothing broke immediately. That was the dangerous part.

Pressure 2: logic

The second pressure came from logic.

As soon as prompts needed to behave differently based on context, teams usually took one of two approaches.

Approach 1: branching in code and concatenating strings

This pattern is common. The system decides which instructions to include, and the prompt is assembled step by step.

This works. The behavior is explicit. You can see exactly which rules apply in which case.

But the cost shows up as the system grows. Testability is weak because individual rules are hard to exercise in isolation. Maintainability suffers as strings grow and conditions multiply. Reuse often means copying text. A small change in one place can affect multiple flows.

Over time, reading this kind of prompt feels more like debugging than designing.

Example:

function buildPrompt(options: {
  userType: "enterprise" | "standard";
  environment: "prod" | "staging";
}) {
  let prompt = `
Role
You are a senior QA engineer designing API test plans for production services.
`;

  // persona
  prompt += `
Persona
${
  options.userType === "enterprise"
    ? "You are thorough and risk-aware. You prioritize reliability and compliance."
    : "You are pragmatic and efficient. You prioritize high-signal coverage."
}
`;

  // input contract
  prompt += `
Input
- userType: ${options.userType}
- environment: ${options.environment}
`;

  // steps
  prompt += `
Steps
Step 1: Read the provided input and treat it as the contract.
Step 2: Derive test categories: happy path, validation, error handling, auth, rate limiting, idempotency.
Step 3: Generate test cases with realistic inputs and expected responses.
Step 4: Validate that every field in output strictly matches output schema.
`;

  // tasks
  prompt += `
Tasks
1. Generate a test plan for the given API.
2. Return only JSON that matches output schema.
`;

  // constraints baseline
  prompt += `
Constraints
- Do not include explanations or markdown.
- Do not output extra keys beyond output schema.
- Keep test cases safe for the given environment.
`;

  // guardrails
  prompt += `
Guardrails
- Do not invent endpoints that are not implied by the API name and context.
- Do not include secrets or real tokens.
- If information is missing, leave a placeholder value and continue.
`;

  // conditional constraints
  if (options.environment === "prod") {
    prompt += `
Constraints
- Avoid destructive test cases. Prefer read-only or safely reversible operations.
`;
  }

  if (options.userType === "enterprise") {
    prompt += `
Constraints
- Include edge cases, rate limiting, and failure scenarios.
`;
  }

  // output
  prompt += `
Output
- Return a single JSON object.
- JSON must match output schema exactly.
- Each test case must follow the schema: { name, description, request, expectedResponse }.
- Output only valid JSON.
`;

  return prompt;
}

Approach 2: delegating logic to the LLM

To avoid string concatenation, some teams push the branching logic into the prompt, describe the rules inside the prompt, and ask the model to apply them.

This looks cleaner at first. There is less code. Everything lives in one place.

But the trade-offs move elsewhere. Logic becomes implicit. Behavior depends on how the model interprets the rules. Testability drops. Debugging becomes guesswork. A small wording change can alter behavior in ways that are hard to predict or reproduce.

When this fails in production, it is often unclear why. Was a rule ignored? Was it interpreted differently? Did a small phrasing change shift the model’s behavior?

Example:

function buildPrompt(options: {
  userType: "enterprise" | "standard";
  environment: "prod" | "staging";
}) {
  return `
Role
You are a senior QA engineer designing API test plans for production services.

Persona
Adjust your behavior based on the following rules:
- If userType is enterprise, be thorough and risk-aware. Prioritize reliability and compliance.
- If userType is standard, be pragmatic and efficient. Prioritize high-signal coverage.

Input
You will receive:
- userType: ${options.userType}
- environment: ${options.environment}

Steps
Step 1: Read the provided input and treat it as the contract.
Step 2: Derive test categories: happy path, validation, error handling, auth, rate limiting, idempotency.
Step 3: Generate test cases with realistic inputs and expected responses.
Step 4: Validate that every field in output strictly matches the output schema.

Tasks
1. Generate a test plan for the given API.
2. Return only JSON that matches the output schema.

Constraints
- Do not include explanations or markdown.
- Do not output extra keys beyond the output schema.
- Keep test cases safe for the given environment.

Apply additional rules:
- If environment is prod, avoid destructive test cases. Prefer read-only or safely reversible operations.
- If userType is enterprise, include edge cases, rate limiting, and failure scenarios.

Guardrails
- Do not invent endpoints that are not implied by the API name and context.
- Do not include secrets or real tokens.
- If information is missing, leave a placeholder value and continue.

Output
- Return a single JSON object.
- JSON must match the output schema exactly.
- Each test case must follow the schema: { name, description, request, expectedResponse }.
- Output only valid JSON.
`;
}

Some teams mix both approaches, but the underlying problems remain.

Pressure 3: structured outputs

The third pressure came from structured outputs.

Once prompts were expected to return structured data (ex: JSON) that fed directly into the next step of the system, failures became more visible. Parsing errors. Schema mismatches. Downstream crashes.

OpenAI introduced structured outputs and schema-based responses. Frameworks like the Vercel AI SDK added output validation and explicit error handling, so invalid responses fail fast before reaching the next step.

These tools solved an important part of the problem. They made failures explicit and protected downstream systems.

But they focus on validating the output. They do not address how prompts themselves are structured or evolved over time.

Introducing composable prompts with promptfmt

Composable prompts are my attempt to address this gap.

Instead of treating a prompt as one growing string, you treat it as a composition of parts. Each part has a clear responsibility. Logic is explicit. Reuse is intentional.

This idea is not new.

SQL moved from raw strings to query builders so queries could be composed safely. HTML moved from templates to components so structure and logic could scale.

I believe prompts can follow a similar path.

I built prompfmt for experimenting with this idea, the earlier prompt can be refactored without changing its behavior. What changes is the shape.

import { PromptBuilder, createCondition } from "promptfmt";

function buildPrompt(options: {
  userType: "enterprise" | "standard";
  environment: "prod" | "staging";
}) {
  return new PromptBuilder()
    .role("You are a senior QA engineer designing API test plans for production services")
    .persona((params) => {
      if (params.userType === "enterprise") return "You are thorough and risk-aware. You prioritize reliability and compliance.";
      return "You are pragmatic and efficient. You prioritize high-signal coverage.";
    })
    .steps([
      "Read the provided input and treat it as the contract",
      "Derive test categories: happy path, validation, error handling, auth, rate limiting, idempotency",
      "Generate test cases with realistic inputs and expected responses",
      "Validate that every field in output strictly matches output schema",
    ])
    .tasks([
      "Generate a test plan for the given API",
      "Return only JSON that matches output schema",
    ])
    .constraints([
      "Do not include explanations or markdown",
      "Do not output extra keys beyond output schema",
      "Keep test cases safe for the given environment",
    ])
    .guardrails([
      "Do not invent endpoints that are not implied by the API name and context",
      "Do not include secrets or real tokens",
      "If information is missing, leave a placeholder value and continue",
    ])
    .constraints({
      condition: createCondition(
        (params) => params.environment === "prod",
        "Avoid destructive test cases. Prefer read-only or safely reversible operations."
      ),
    })
    .constraints({
      condition: createCondition(
        (params) => params.userType === "enterprise",
        "Include edge cases, rate limiting, and failure scenarios."
      ),
    })
    .output([
      "Return a single JSON object",
      "Each test case must include: name, description, request, expectedResponse",
    ])
    .build(options);
}

And these are the expected outputs.

// console.log(buildPrompt({userType: "enterprise", environment: "prod"));
Role
You are a senior QA engineer designing API test plans for production services

Persona
You are thorough and risk-aware. You prioritize reliability and compliance.

Steps
Step 1: Read the provided input and treat it as the contract
Step 2: Derive test categories: happy path, validation, error handling, auth, rate limiting, idempotency
Step 3: Generate test cases with realistic inputs and expected responses
Step 4: Validate that every field in output strictly matches output schema

Tasks
1. Generate a test plan for the given API
2. Return only JSON that matches output schema

Constraints
- Do not include explanations or markdown
- Do not output extra keys beyond output schema
- Keep test cases safe for the given environment

Guardrails
- Do not invent endpoints that are not implied by the API name and context
- Do not include secrets or real tokens
- If information is missing, leave a placeholder value and continue

Environment Constraints
Avoid destructive test cases. Prefer read-only or safely reversible operations.

Constraints
Include edge cases, rate limiting, and failure scenarios.

Output
Return a single JSON object
Each test case must include: name, description, request, expectedResponse

// console.log(buildPrompt({userType: "standard", environment: "staging")));
Role
You are a senior QA engineer designing API test plans for production services

Persona
You are pragmatic and efficient. You prioritize high-signal coverage.

Steps
Step 1: Read the provided input and treat it as the contract
Step 2: Derive test categories: happy path, validation, error handling, auth, rate limiting, idempotency
Step 3: Generate test cases with realistic inputs and expected responses
Step 4: Validate that every field in output strictly matches output schema

Tasks
1. Generate a test plan for the given API
2. Return only JSON that matches output schema

Constraints
- Do not include explanations or markdown
- Do not output extra keys beyond output schema
- Keep test cases safe for the given environment

Guardrails
- Do not invent endpoints that are not implied by the API name and context
- Do not include secrets or real tokens
- If information is missing, leave a placeholder value and continue

Output
Return a single JSON object
Each test case must include: name, description, request, expectedResponse

Structure becomes visible. Logic is explicit. Each rule exists as a first-class piece instead of being buried inside text. That makes prompts easier to change and safer to evolve.

Most importantly, prompts become more testable, maintainable, and predictable.

• Individual rules can be validated in isolation instead of only through end-to-end runs.
• Adding a new condition does not require rewriting or copying large blocks of text.
• Changes have clearer boundaries and fewer unintended side effects.

These qualities are not optional in software engineering. They are the baseline that allows systems to scale.

But there are trade-offs.

Composable prompts add abstraction. They introduce a learning curve. They do not magically solve prompt quality.

There are also cases where this approach is unnecessary. One-off prompts. Prototypes. Low-risk flows that do not return structured data.

But for prompts that sit in the middle of real systems, composability aligns better with how the rest of the codebase evolves.

Closing

Prompts are no longer just text.

They are reused. They carry logic. They return structured data that other systems depend on. That makes testing, maintainability, and clarity important.

As prompts become a stable part of systems, tooling will follow.

promptfmt is one small experiment in that direction. It is early, and it should improve and evolve with real usage and feedback.

If this perspective resonates with you, check it out and contribute ideas or improvements.

If you want to read more about software engineering in the AI era, subscribe to my blog. I will keep sharing what I learn while building systems with AI in the loop.

It does not.

Output is cheap now. Anyone can create something. The real question is whether that something solves the right problem. And this is where the gap becomes obvious.

I see this a lot in the way people talk about AI. You can find countless examples of “I built this in 10 minutes”. Some look exciting. But if you check the details, most of them do not solve a real user problem. They are not reliable. They cannot run in real conditions. They fall apart the moment you try to scale or integrate them.

The same pattern shows up at work. People generate things quickly, but the output does not always move the problem forward. It creates noise rather than progress. People ask AI to generate code they cannot debug. Others create a dozen screens without understanding the flow. Some write long documents that do not clarify anything. It feels productive because something appears on the screen, but the output becomes a distraction.

Productivity has never been about the amount of output. Productivity is about solving the right problem with the most efficient solution. To do that, you need domain knowledge. You need context. You need experience making trade-offs. AI cannot do this part for you.

AI can help you move faster. But only if you know where you are going. Without expertise, AI just accelerates confusion. You get more things, not better things. This is why strong practitioners get a clear advantage. They use AI to amplify their judgment. They ask better questions. They evaluate solutions. They know what good looks like. AI becomes the leverage.

Weak practitioners do not get the same effect. AI gives them more surface area to cover, more decisions to make, and more ways to make mistakes. Their lack of fundamentals becomes more visible. They ship faster, but also break things faster.

For non-engineers, this is important to understand. AI will not replace the need for expertise. It will not turn you into an engineer or a designer, or a product builder overnight. It reflects how much clarity you already have. If you do not understand the problem deeply, AI cannot fix that. It can only generate more output that you cannot evaluate.

There is also a common argument online comparing AI-generated code with compiled code from a compiler. They argue that if we do not review compiler output, we should not need to review AI output. They miss the key point. A compiler follows a deterministic algorithm. It transforms your code into machine code in a predictable and verifiable way. AI does not work like that. You cannot predict what AI will generate, and you cannot assume correctness from an LLM model.

Some people say, if the code can run, why do I need to check the code? While it’s true, running code only proves the happy path. It does not prove correctness, reliability, security, or long-term cost. It only shows that one specific scenario worked once. And in real systems, that is not enough.

The real multiplier is still the same. AI plus domain expertise. AI takes your strengths and scales them. It also takes your weaknesses and scales them. This makes the fundamentals even more important. Focus on your strength, don’t scale your weaknesses. Thinking clearly. Understanding problems. Making good decisions.

If you enjoy thoughts like this, follow me. I share what I learn as we navigate the AI era together.

As someone who uses Cursor every day, I couldn’t wait to try out the new 2.0 release. I spent some time exploring what’s new. Here’s my experience with the 2.0 release.

Composer model

One of the biggest highlights in Cursor 2.0 is Composer, the team’s first in-house AI coding model. Cursor describes it as a “frontier model” that delivers the same level of capability as others, but 4x faster. From my own testing and what others have shared, it definitely feels fast, making quick iterations smoother.

To see how well Composer performs, I tried the same test as I did before with the frontier models. But in this case, I will do it a bit differently, once is with a simple prompt of the requirement and once using my structured AI workflow (AI DevKit, which adds planning and testing steps around the agent).

Without AI DevKit

Composer jumped straight into coding and finished in about 2 minutes. The speed was amazing. I had working code almost immediately. However, the solution felt like a quick prototype.

The code was functional but bare-bones, lacking polish. I noticed I’d still need to tweak things (refactor some parts, add error handling, etc.) before considering it production-ready. It reminded me of the kind of output I’d get from Grok Code Fast 1 from the previous test.

About the speed, it’s fast, but still a bit behind what Claude Sonnet 4.5 performed in the previous test.

With AI DevKit

The process took longer overall (around 8 minutes total: ~2 min planning, 4 min coding, 2 min testing), but the outcome was much more robust. Composer first spent time generating a plan (breaking down the task, clarifying requirements), then wrote the code, and finally ran tests/verification.

The resulting code quality was night-and-day compared to the quick run. It implemented features like lazy-loading of data, navigating between images via keyboard, included proper error handling.

The code structure was cleaner, and the agent’s own test run. In short, this more thorough run produced output on par with what GPT-5 Codex produced in the previous test, much closer to production-ready.

In summary, Composer is quite amazing in the speed, but to compare with other frontier models such as Claude Sonnet 4.5 or GPT-5 Codex, it still needs a bit more guidance. If you just need a quick prototype, letting it run freely gets you results in no time. But if you spend a bit more time, either manually or with a workflow such as AI DevKit, the quality jumps significantly, making the output solid enough for real development.

Since the cost of Composer is similar to GPT-5 Codex, I still think Codex is a better choice if putting them side by side. But if you prefer the speed, you can consider Composer over GPT-5 Codex.

Output:

Without AI DevKit

With AI DevKit

Line of code:

Without AI DevKit

With AI DevKit

Multi-Agents

Personally, I think the new UI in Cursor 2.0 isn’t a big change. The agent view and editor view still look familiar, the main difference is the layout and where the panels are placed. We could already run multiple chats at the same time before this update, so the multi-agent interface isn’t entirely new, it’s just presented more clearly.

Agent UI

Editor UI

Under the hood, it uses git worktrees to give each agent its own isolated workspace so they don’t step on each other’s changes. In practice, this meant I could spin up a couple of agents to tackle different features (or the same feature with different approaches) without worrying about merge conflicts. The next problem is that “Does your laptop have enough resources to run multiple agents at the same time?”.

Functionally, running parallel agents worked smoothly for me. The UI allowed me to switch between each agent’s conversation and see their progress. One capability the Cursor team highlighted is that you can even have multiple models attempt the exact same prompt in parallel, then compare the results and pick the best solution. For example, you might run Composer alongside an OpenAI GPT-5 Codex agent, maybe even a Claude model, all tackling your feature request simultaneously. The idea is that for tough problems, this increases the chance that at least one agent comes up with a great solution. It is pretty cool to watch different AIs coding in parallel and then cherry-pick the winner or even combine insights.

That said, I’m not sure how often I’d use multi-model parallelism in everyday development. It definitely consumes more tokens/compute (since you’re effectively paying for two or three models to do the job of one), which might not be justified for routine tasks. I see it as a powerful feature for benchmarking model quality or tackling a really difficult problem where you want extra assurance. For most day-to-day feature builds, a single capable model usually suffices.

Overall, the new UI is cleaner and a bit more convenient, but it doesn’t fundamentally change how you work with Cursor.

Other highlights

Code review

One improvement I did notice is that all file changes are now grouped into a single review tab. In earlier versions, you had to open each file separately to see what the agent changed. Now, you can review everything in one place, similar to how we check diffs on GitHub or GitLab. It’s a small change, but it makes reviewing easier and more natural.

In-app Browser

I was really excited about the new built-in browser/DOM inspector tool.

Cursor 2.0 now has a native browser panel that the agent can use to run, test the app, and also forward DOM information to the agent within the editor. In earlier versions, I had to set up a separate Model Context Protocol (MCP) server to let the AI agent interface with a browser for similar thing. This feature will significantly help front-end developers.

Other than that, Cursor 2.0 introduced a Voice Mode, which lets you control the coding agent with speech commands. Using built-in speech-to-text, you can speak your prompt or instructions, and even use custom trigger words to tell the agent when to start coding. I gave this a brief try, and to be honest, I don’t see how it is useful. Personally, I prefer the silence of typing and thinking through the problem. In my workflow, I often need to pause and consider output, tweak a prompt, etc., and doing that out loud felt a bit awkward.

Final take

After a few days of playing with Cursor 2.0, my overall impression is positive. Cursor 2.0 feels like a solid improvement rather than a big leap.

Composer is a good model, but it will need some time to catch up with other frontier models. Composer is fast, and when used with a structured workflow, it can produce reliable, production-ready code.

The review flow is easier to follow, but most of the core experience remains familiar. Multi-agent mode and the in-app browser are interesting additions.

Overall, it’s a nice upgrade that makes Cursor more polished and practical for everyday development.

My first thought was the usual: “Is it us?”. I checked Docker health and found an incident from their side. Two minutes later, Twitter/X confirmed it wasn’t just us. AWS was having a bad day, and a big chunk of the internet came along for the ride.

This post is a short reflection on that incident. We were lucky, our systems run in a few different regions and were not directly connected to the broken services. But there were many lessons to learn.

What actually went down

On the AWS website, they shared that the outage started with a DNS failure in DynamoDB, triggered a chain reaction across key AWS systems (EC2, Lambda, SQS), and later exposed a deeper problem in AWS’s internal network monitoring. It impacted 141 AWS services and lasted about 15 hours before everything stabilized. The detailed post-event report can be found here. If you want to learn more about how the incident happened, Gergely Orosz has a good deep dive in his newsletter, The Pragmatic Engineer.

The incident affected thousands of companies. When AWS went down, it wasn’t just a tech issue, it stopped businesses in their tracks. A few hours offline can mean lost sales, missed deadlines, and frustrated customers. Every major outage reminds teams to take a hard look at how fragile their setup might be.

The incident also highlighted the trade-off we’ve made with the cloud. Using AWS, Azure, or Google Cloud is fast, simple, and cheaper upfront compared to running your own data center. You don’t need to buy servers, manage power, or hire people to maintain racks. But the convenience comes with a cost: less control and higher dependency. When one cloud region fails, you wait for them to fix it. Running your own data center costs more in hardware and staff, yet you can decide how it’s built, tested, and recovered. Most teams choose the cloud because it speeds up development, removes the overhead of operation, but the AWS outage reminded us that saving time can mean giving up some control.

We also experienced several major incidents due to the Cloud provider in the past. I remember the Cloudflare outage we experienced. Our system was down because our DNS and CDN were tied to Cloudflare’s network, and when Cloudflare sneezed, everyone caught a cold. We realized we had no quick fallback; we just had to wait it out. Similarly, the AWS outage made companies large and small realize that “wait it out” shouldn’t be the only plan.

If your application, backend, databases, etc, are all tied to one provider and one region, that’s a single point of failure. And you can do it at your own risk. Being “production-ready” nowadays means being failure-tolerant by default.

So, what do we do about it? No cloud provider is perfect, AWS, Google, Microsoft, Cloudflare, you name it, they all have bad days. We can’t prevent outages, but we can prepare for them. Below are key strategies and techniques that we learned and implemented in our team to mitigate the impact of outages.

Key Strategies for Resilience

Here are approaches we’ve used and seen others use to stay online and recover quickly when cloud problems happen:

Deploy across multiple Availability Zones and Regions

• At a minimum, deploy your critical workloads in a multi-AZ setup (multiple data centers in one region) so an isolated data center failure won’t take you down. But given regional outages like this one, consider multi-region redundancy for truly critical systems.
• Whether you do active-active (serving traffic from two regions at once) or active-passive (warm standby in a second region), having a Plan B region can turn a regional outage into a minor performance problem rather than a full shutdown.
• Multi-region adds complexity (data replication, syncing configs, etc.) and cost, of course, but it increases resilience.

Design for Graceful Degradation

• Not every part of your application needs to work 100% for the core experience to survive. Identify which features can fail gracefully. Decouple your architecture so that if one service or dependency goes down, it doesn’t drag everything with it.
• In practice, this might mean using queues and async processing. If your database is having issues, perhaps you queue up writes for later, serve cached data, or switch to a read-only mode. The goal is to fail softly, users get a lighter version of your app instead of a blank error screen. We follow this approach in our app at ShopBack so that if our API gateway ever fails to respond for any reason, users can still access cached read-only data.

Regular Backups and Cross-Cloud Backups

• Outages often remind us of the value of backups. Make sure you regularly back up your data and store those backups in a different region or even outside your current Cloud provider.
• For example, you might periodically export critical data from your AWS database to an on-premises server or another cloud’s storage. That way, if AWS is down hard, you haven’t lost data, and you could even spin up a read-only instance elsewhere in a pinch. Define your RTO (Recovery Time Objective). Basically, how long you can afford to be down and how much data you can lose, and architect the infrastructure and system to meet those targets.
• A case study of this is the cyberattack on one of the biggest stock exchanges in Vietnam in 2024. In that case, the company kept all its backups in the same cloud environment. When attackers gained access, they froze both the main system and the backups, making recovery impossible. It took them the whole week to recover. If those backups had been stored elsewhere, the outcome could have been very different.
• The main downside of cross-cloud backups is cost and the extra effort needed to manage them.

Disaster Recovery Drills

• When an outage hits, every minute counts. You don’t want to be clicking around the console, spinning up resources in a panic. Use Infrastructure as Code and automated scripts for your failover plans. Set up processes that can quickly spin up your systems in another region or on a different provider when something goes wrong.
• Run Disaster Recovery Drills to practice this failover. For example, occasionally simulate “What if us-east-1 dies?” and see if your team can restore service from backups or switch DNS to your secondary site within your RTO window. Practice not only finds the gaps in your plan but also makes the real thing much less chaotic.
• Don’t forget to test your communications during such drills, ensure the team can communicate even if your primary systems (or Slack/email) are down.
• At ShopBack, we run this exercise every year and set tight goals for how fast we can rebuild our environment from scratch.

Monitoring and Observability of Dependencies

• One sneaky lesson from outages is that sometimes services you didn’t think were critical turn out to be. In this case, many teams were surprised to find that even services running in other AWS regions or seemingly independent systems failed because they secretly depended on something in us-east-1.
• We need to map out the dependencies. What happens if Service A can’t talk to Service B? Do you know all the external APIs, auth services, or resources that your stack relies on? Use monitoring tools to catch these hidden dependencies and set up alerts for any unusual latencies or failures in them. During normal times, this helps you catch issues early; during an outage, it can pinpoint which dependency is the weak link causing cascading failures.
• Also, keep an eye on your external and third-party services. After several incidents involving them, at ShopBack, we set up a dedicated Slack alert channel to monitor the health of these integrations separately.

Consider Hybrid and Multi-Cloud Approaches

• This is the big guns. Not every company can afford to do it. It’s expensive and requires extra effort and maintenance to manage well. “Multi-cloud” means using more than one cloud provider, while hybrid setups combine cloud services with your own on-premises servers. Both are often seen as ways to reduce reliance on a single provider.
• They’re not trivial to implement, but for some businesses, they can be worth it. The goal is to run some of your systems on another provider or your own servers so that if one fails, the others keep working.

Systems will have bugs, and incidents will happen. We can’t control when AWS or any provider has issues, but we can control our preparedness and response. The latest AWS outage reminded us of that. By learning from it and from our own war stories (yes, Cloudflare, I’m looking at you), we can keep our applications not just running on sunny days, but resilient through the storms.

Stay safe out there in the cloud! And next time AWS goes dark, may your systems stay comfortably in the light.

If you love my blogs, please subscribe for more engineering lessons on building reliable systems.

Understand requirement → Design → Plan → Implement → Review → Test → Deploy → Monitor.

That hasn’t changed for a long time. When AI is involved in the workflow, what’s changed is the speed. I also mentioned this in my FREE eBook about adapting AI in Software Engineering.

Before AI, a typical cycle for mid-sized features often stretched over several weeks. Each step involved back-and-forth reviews, context switching, and waiting for feedback. But with tools like Cursor (and yes, even Claude Code), the same workflow can now run faster. I mentioned this in the post How much faster can AI actually make your team?.

I’ve been experimenting with this new way of working for a while, the last time I talked about this was in my post about my learning after using CursorAI for 9 months. Eventually, I decided to turn my setup into a reusable toolkit, I called it ai-devkit, so that I can share it with others and make AI-assisted workflows consistent across projects.

Let’s walk through how my engineering workflow actually looks today, step by step.

Engineering Workflow (Before AI)

Whether you’re at a startup or a big tech company, the core process looks like this:

1. Understand Requirement: Read the PRD or tickets, clarify what’s being asked.
2. Review Requirement: Identify gaps, edge cases, or unclear assumptions.
3. Design: Draft your architecture, data model, or API contract.
4. Review Design: Discuss with peers or leads to validate approach.
5. Plan: Break it into tasks, estimate effort, and define milestones.
6. Implement: Write the code, debug, and document.
7. Review Implementation: Peer review for quality and maintainability.
8. Testing: Unit, integration, or E2E coverage before shipping.
9. Deploy & Monitor: Release safely and track metrics or logs.

Each phase produces something tangible: a document, a design, a Pull Request (PR) or Merge Request (MR), or a deployment. Every phase waited for human feedback or context setup, so it could take weeks or months for even a mid-sized feature.

AI-Accelerated Workflow

To make this section easier to navigate, I’ve broken it down into two parts: Feature development and Understanding existing code.

Feature development

The workflow itself didn’t change, we just execute it differently now. I personally use Cursor as the default editor and tried to tighten the workflow with it, although I was a Neovim user for many years.

I use Cursor Commands to create reusable workflows so that I don’t need to repeat myself.

You can create commands yourself. Or you also can easily scaffold the working environment with npx ai-devkit init. You can choose your environment, such as Cursor or Claude Code, so that it will set up the files accordingly.

Here’s how it looks with ai-devkit:

1. Understand Requirement
   • In the Cursor AI Chat (or Claude Code), use the /new-requirement command to summarize goals, constraints, and success metrics.
   • This prompt will try to highlight what’s unclear and what assumptions you’re making.
2. Review Requirement
   • After finishing running /new-requirement commands, you now have all your required documents in docs/ai/. At this stage, we will review the files so that we won’t miss anything. I usually manually review this so that I will stay on top of the work.
   • Ask Cursor to review the requirement by using the command /review-requirement.
   • The output helps spot what the original specs might have missed.
3. Design
   • When running /new-requirement it will also propose a design in docs/ai/design.
   • I often generate multiple options, compare trade-offs, and refine manually.
4. Review Design
   • To support this, I have a command /review-design so that Cursor can act like a simulated peer reviewer, which challenges design decisions and reminds me about different things that I overlooked.
5. Plan
   • Convert the design into concrete steps and a checklist.
6. Implement
   • This is where AI tools such as Cursor or Claude Code shine.
   • Whenever we finish reviewing all the design and plan documents, we can run /execute-plan the tool will pick up the tasks one by one and execute them.
   • Whenever the implementation is done, you can run check-implementation to make sure the code follows the requirements.
   • You will need to manually review the code with the support of /code-review, so that you still own the quality of the code.
7. Testing
   • Run /writing-test to create unit and integration tests targeting high coverage.
8. Deploy & Monitor
   • Cursor helps generate release notes, deployment steps, monitoring metrics, and alerts.

I still think through the same steps, but AI keeps the flow unbroken. It helps me stay in problem-solving mode longer.

Understanding existing code

A big part of coding is understanding the code that’s already there. For years, reading and making sense of existing code has been one of the hardest things, especially for newer engineers.

Now, AI can help speed up that process. It can describe what a piece of code is doing, show you where it’s being used, and help you understand how different parts fit together.

With ai-devkit, you can use /capture-knowledge command helps you understand how existing code works by analyzing it from any entry point and generating comprehensive documentation with visual diagrams.

Know when to use MCP

When working inside Cursor or Claude Code, not everything needs to run through a Model Context Protocol (MCP) server. MCP is extremely useful when you need live integration between tools, but many workflows are still more practical using existing CLIs.

For example, I use the Figma MCP server to fetch design details directly into Cursor. It saves time when I need to reference a component or color spec while coding. Similarly, I rely on the Atlassian MCP server to fetch Jira ticket or Confluence information automatically when running /new-requirement, which keeps requirements in sync.

However, not every integration benefits from MCP. For GitLab, I prefer to use the GitLab CLI instead of setting up an MCP server. It’s faster, simpler, and perfectly fine for tasks like creating MR. Sometimes, adding MCP just for the sake of it adds unnecessary complexity.

Use MCP when context-sharing between AI and external tools makes your workflow smoother, but don’t force everything into the MCP pattern. Command-line tools and direct editor integrations are often more efficient for straightforward tasks.

Why I Built ai-devkit

Before ai-devkit, I used to keep a folder of prompts. Every time I needed to start something new, I copied one prompt into Cursor, adjusted the wording, and ran it. It worked, but it was manual, inconsistent, and error-prone. Sometimes the context is lost in the middle.

So I bundled everything into a single, reusable setup ai-devkit. It gives me consistency across projects and lets others benefit too.

You can use it directly in Cursor, or even Claude Code, and that is your choice. The structure is universal, it just depends on how you integrate prompts into your workspace.

Real Example: Better Output, Lower Cost

In my previous post, I compared Claude Sonnet 4.5, GPT-5 Codex, and Grok Code Fast 1. Grok Code Fast 1 was fast, but produced incomplete code.

When I tested the same task again using ai-devkit with the /new-requirement command in Cursor with Grok Code Fast 1, it was fast, the result was good on the first try, and the cost was much lower compared to the other models.

Model matters, but what we give to the model matters more.

The future of AI-assisted Engineering

AI is now part of the engineering workflow, it amplifies, not replaces, human engineers in the workflow. We are augmented by it.

The phases remain the same, but the cycle time is reduced. You still need to think clearly, design responsibly, and test thoroughly. AI just helps you get there faster, with less friction between steps.

I see this as the new normal: Engineers still own the craft, but they now have powerful copilots to accelerate it.

If you’re curious to explore this kind of workflow, try ai-devkit. Use it, experiment with your own commands, or even extend it with better prompts. All contributions are welcome.

I wanted to understand how this works in practice, so I decided to build something small: a to-do app (because, well, this is something you build when you learn something new).

Here’s the plan:

• We’ll build a ChatGPT App that can read, write, and sync a to-do list in real time.
• We’ll keep things simple: no database, no cloud setup, no fancy frameworks.
• We’ll use JavaScript, Express, React, and MCP (Model Context Protocol).

It’s the easiest way to see how to build a simple ChatGPT App in real life. This tutorial walks through that process from scratch: how to build, connect, and finally, make ChatGPT aware when your app updates.

Here’s the flow we’re going for:

1. You ask ChatGPT: “Add create tutorial to my to-do list.”
2. ChatGPT calls your MCP tool addTask.
3. The server stores the task in memory.
4. The React UI updates instantly to show it.
5. Later, when you check a task off in the UI, ChatGPT knows it happened.

That last step is the interesting one, your app notifying ChatGPT when something changes. We’ll get there.

You’ll only need a few things to follow along. Make sure you install them before going to the next steps.

• Node.js
• npm (this is included when you install Node.js)
• ngrok (for exposing your local machine to the internet)

Let’s start clean.

Here is the folder structure that we will set up:

chatgpt-app-todo/
├── server/ # Express + MCP server
│ ├── index.js # Entry point for backend
│ └── package.json
├── client/ # React frontend
│ ├── src/
│ │ └── App.jsx # Main UI component
│ ├── index.html
│ └── package.json

In your terminal, just run these commands:

mkdir chatgpt-app-todo
cd chatgpt-app-todo
mkdir server client

Build the Server

The server will do two things:

1. Provide a basic REST API that the React app can talk to.
2. Register MCP tools and resources so ChatGPT can call them.

Let’s start with the basics.

Inside /server, we will install some simple dependencies before coding.

cd server
npm install --save express cors body-parser
touch index.js

In index.js, we will create a simple server to handle some basic endpoint to create tasks, list tasks, and mark task as completed.

import express from "express";
import cors from "cors";

const app = express();
app.use(cors());
app.use(express.json());

let tasks = [];

app.get('/tasks', (req, res) => res.json(tasks));
app.post('/tasks', (req, res) => {
  const newTask = { id: Date.now(), text: req.body.text, completed: false };
  tasks.push(newTask);
  res.json(newTask);
});

app.post('/tasks/:id/complete', (req, res) => {
  const task = tasks.find(t => t.id === +req.params.id);
  if (task) task.completed = true;
  res.json(task);
});

app.listen(3000, () => console.log('Server running on http://localhost:3000'));

Now you can run your server with node index.js.

You should see Server running on http://localhost:3000. When you visit http://localhost:3000/tasks you will receive an empty array [].

That’s the simplest version of the API and perfect for now. If you are a software engineer, this only takes a few minutes.

Build the Client

We’ll keep this simple too. We will spin up a new React app with JavaScript using Vite. In client, run

cd client
npm create vite@latest

Answer some questions to create the app, remember to choose React and JavaScript.

Update src/App.tsx with this, to create a quick Todo interface.

import { useEffect, useState } from "react";

export default function App() {
  const [tasks, setTasks] = useState([]);
  const [text, setText] = useState("");

  const fetchTasks = async () => {
    const res = await fetch("http://localhost:3000/tasks");
    setTasks(await res.json());
  };

  const addTask = async () => {
    if (!text.trim()) return;
    await fetch("http://localhost:3000/tasks", {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({ text }),
    });
    setText("");
    fetchTasks();
  };

  const completeTask = async (id) => {
    await fetch(`http://localhost:3000/tasks/${id}/complete`, {
      method: "POST",
    });
    fetchTasks();
  };

  const handleKeyPress = (e) => {
    if (e.key === "Enter") {
      addTask();
    }
  };

  useEffect(() => {
    fetchTasks();
  }, []);

  const completedCount = tasks.filter((t) => t.completed).length;
  const totalCount = tasks.length;

  return (
    <div>
      <h1>Task Tracker</h1>
      <p>Stay organized and productive</p>

      {totalCount > 0 && (
        <div>
          <span>Progress: {completedCount} of {totalCount} completed</span>
          <div>
            <div style={{ width: `${progress}%`, background: "blue", height: "5px" }}></div>
          </div>
        </div>
      )}

      <div>
        <input
          value={text}
          onChange={(e) => setText(e.target.value)}
          onKeyPress={(e) => e.key === "Enter" && addTask()}
          placeholder="What needs to be done?"
        />
        <button onClick={addTask}>Add Task</button>
      </div>

      <div>
        {tasks.length === 0 ? (
          <p>No tasks yet. Add one to get started!</p>
        ) : (
          tasks.map((t) => (
            <div key={t.id}>
              <input
                type="checkbox"
                checked={t.completed}
                onChange={() => completeTask(t.id)}
              />
              <span style={{ textDecoration: t.completed ? "line-through" : "none" }}>
                {t.text}
              </span>
            </div>
          ))
        )}
      </div>
    </div>
  );
}

I also added Tailwind to make it not boring. For setting up Tailwind, you can refer to the instructions here. It is pretty straightforward.

Now, when you run the app with npm run dev, then visit http://localhost:5173/ you now have a fully functional Todo app.

When you run npm run build, you will see your app artifact in client/dist folder.

That’s all the easy part, you might take a few minutes on this, the next part we will focus on building MCP (Model Context Protocol) server and connect the app with ChatGPT.

Building the MCP server

By now, you have a working local app:

• A small Express server that stores your tasks in memory.
• A React frontend that lets you add or complete tasks.

Now it’s time to make ChatGPT part of the loop.

Here is the high-level of the architecture when building ChatGPT app.

If you want to learn more about MCP, you can visit here. I also had another post to explain about MCP and why it matters.

For this tutorial, you can understand MCP as a bridge between ChatGPT and external systems. With it, ChatGPT can:

• Call your functions (called “tools”): for example, add a new task or get a list.
• Render custom UIs inside ChatGPT: using small HTML widgets (iframes).
• Exchange structured data between your app and ChatGPT.

In order to add MCP to your server, you need to install 2 dependencies

npm i --save @modelcontextprotocol/sdk zod

Register resource

Back to your server/index.js, add this code:

const createMcpServer = () => {
  const server = new McpServer({
    name: 'Todo List',
    version: '1.0.0',
  });

  const html = fs.readFileSync(path.join('../client/dist', 'index.html'), 'utf8').trim();
  server.registerResource(
    "chatgpt-app-todo-widget",
    "ui://widget/chatgpt-app-todo.html",
    {},
    () => ({
      contents: [{
        uri: "ui://widget/chatgpt-app-todo.html",
        mimeType: "text/html+skybridge",
        text: html
      }]
    })
  );

  return server;
};

The createMcpServer function is for creating your MCP server. This reads the final built HTML file from your React app. We’ll send this HTML to ChatGPT so it can display your UI directly inside its own window through an iframe.

There are something to note:

• registerResource() lets you expose files or data that ChatGPT can use as visual components or structured resources.
• The ui://widget/...html URI is just a convention so that ChatGPT understands this is a UI.
• mimeType: "text/html+skybridge" tells ChatGPT it’s not a normal webpage, it’s an embedded widget that should be rendered inside ChatGPT.
• You could make the return contents dynamic if needed, but here we just return your static HTML.

After this, ChatGPT knows that your MCP server offers a resource called chatgpt-app-todo-widget that can be displayed visually.

Then, you need to provide a way for ChatGPT to connect with your MCP server. In order to do this, you need to expose an endpoint for ChatGPT to call. In your server/index.js, expose an endpoint like this:

app.post('/mcp', async (req, res) => {
  const server = createMcpServer();

  const transport = new StreamableHTTPServerTransport({
    sessionIdGenerator: undefined,
    enableJsonResponse: true
  });

  res.on('close', () => {
    transport.close();
  });

  await server.connect(transport);
  await transport.handleRequest(req, res, req.body);
});

So, when ChatGPT sends an MCP message to POST /mcp, this function makes sure it’s handled end-to-end according to the MCP specifications. In production environment, you will need to handle authentication and authorization, but within this tutorial, we won’t do it.

Now, you have your MCP server. To test the server, you can use MCP Inspector, you can run the inspector with this command.

npx @modelcontextprotocol/inspector

Then, go to http://localhost:6274/, you will get the inspector UI. You can connect to your MCP server by inputting your URL. Click on List Resources, you will see your chatgpt-app-todo-widget.

Please note that whenever you change your MCP server code, you need to reconnect to the MCP server in Inspector to get the latest changes.

Register tool

Now, let’s register a tool that ChatGPT can call when a user says something like “Create a new task: finish reading the MCP tutorial.”

In your createMcpServer function, add this:

  server.registerTool('createTask', {
    title: 'Create a new task',
    description: 'Create a new task',
    inputSchema: {
      text: z.string(),
    },
    outputSchema: {
      id: z.number(),
      text: z.string(),
      completed: z.boolean(),
    },
    _meta: {
      "openai/outputTemplate": "ui://widget/chatgpt-app-todo.html",
      "openai/toolInvocation/invoking": "Creating task...",
      "openai/toolInvocation/invoked": "Task created"
    },
  }, async ({ text }) => {
    const newTask = { id: Date.now(), text, completed: false };
    tasks.push(newTask);
    return {
      structuredContent: newTask,
      content: [
        { type: 'text', text: newTask.text },
      ],
    }
  });

There are 3 parts when you register a tool:

• The tool name.
• The configuration defines what the tool is and how it should behave so that ChatGPT can understand.
• The handler function that runs when ChatGPT calls this tool.

In configuration, you will have:

• The title and description in plain text, so that it can describe the meaning of the tool to ChatGPT.
• The inputSchema and outputSchema tells ChatGPT the shape of data the tool expects and returns. We’re using zod to define and validate types.
• The _meta to explain the user experience when ChatGPT triggers the tool
  • openai/outputTemplate tells ChatGPT which UI widget to show when this tool is used. In our case, it’s the same HTML widget we registered above.
  • openai/toolInvocation/invoking is the message ChatGPT displays while the tool runs.
  • openai/toolInvocation/invoked is what it says when the tool finishes.

In the handler function, there are things you need to note:

• content is the required field; this is for ChatGPT to show to the user.
• structuredContent is for the app; this will be validated with the outputSchema.

We can test this by MCP Inspector, go to List Tools, then select the tool and choose Run tool.

When you can run the tool successfully, you will see the result like this.

You can create other tools, such as get tasks, or mark a task as completed, similar to the example above.

At this point, you already have the MCP server that provides information to ChatGPT about:

• What your app looks like (via the registered HTML resource).
• What actions it can perform (via the registered tools).

Once you start your server and register it with ChatGPT, you’ll be able to chat: “Create a new task: finish reading the MCP tutorial.” ChatGPT will call your tool, update the shared data, and render your widget.

Connect your app with ChatGPT

First, please double-check if your server is running.

Now we will use ngrok to expose your server to the internet so that ChatGPT can connect.

ngrok http 3000

If you have already deployed your server and exposed it to the internet, you won’t need this step.

Now, you need to enable Developer Mode in ChatGPT.

After enabling Developer mode, you will see a red border around the chat box. Then, we can create new Apps by clicking the Create button.

Input your information for the App. Please note that the MCP Server URL must be the one that you exposed through ngrok or your host if you have already deployed the server somewhere. In this tutorial, we will disable authentication for this App.

Click Create to create your App. After creating the App successfully, you will see something like this. Remember that if you change your MCP server, you need to click Refresh to make sure your App syncs with the changes from the MCP server.

Now we can test if our App can show in ChatGPT when we type “@ChatGPT App Todo Create a new task: finish reading the MCP tutorial.”.

Hold on, there is something not right, after it ran the MCP tool to create new task, there was no item in the App UI. What was wrong?

Back to the client/src/App.jsx, we found the issue that there is no communication between ChatGPT and our App. But how can we fix that?

When your App UI (the widget) is rendered inside ChatGPT, it runs in a sandboxed iframe. Within that iframe, the OpenAI Apps SDK injects a global object: window.openai. This gives you safe access to ChatGPT context including:

• Functions to interact with ChatGPT’s runtime (tool calling, sending follow-ups, etc.)
• Global data describing the current widget state (theme, locale, layout, tool input, tool output, etc.)

Now, when the ChatGPT call MCP tool, as mentioned in Building the MCP section, we need to return the structuredContent for the App to use, this value will be included in the global data of ChatGPT context, named toolOutput. So, in this case, we want to listen if the value of toolOutput is changed, then re-render the app to reflect the correct state.

In order to listen to the toolOutput value, let’s create a React Hook for listening the window.openai.toolOutput changes. We will call this useOpenAiGlobal, so that we can listen other value if we need to.

Create client/src/useOpenAiGlobal.js.

import { useSyncExternalStore } from "react";

export const SET_GLOBALS_EVENT_TYPE = "openai:set_globals";

export function useOpenAiGlobal(key) {
  return useSyncExternalStore(
    (onChange) => {
      if (typeof window === "undefined") {
        return () => {};
      }

      const handleSetGlobal = (event) => {
        const value = event.detail.globals[key];
        if (value === undefined) {
          return;
        }

        onChange();
      };

      window.addEventListener(SET_GLOBALS_EVENT_TYPE, handleSetGlobal, {
        passive: true,
      });

      return () => {
        window.removeEventListener(SET_GLOBALS_EVENT_TYPE, handleSetGlobal);
      };
    },
    () => window.openai?.[key] ?? null,
    () => window.openai?.[key] ?? null
  );
}

Then, in your client/src/App.jsx, use the hook that we just defined.

import { useOpenAiGlobal } from "./useOpenAiGlobal";

export default function App() {
  const toolOutput = window.openai ? useOpenAiGlobal("toolOutput") : null;

  if (window.openai) {
    useEffect(() => {
      fetchTasks();
    }, [toolOutput]);
  }
  // The existed code
}

What’s happening inside this code

• It first checks if window.openai exists (meaning the app is running inside ChatGPT’s environment).
• If yes,
  • It calls a custom React hook useOpenAiGlobal("toolOutput").
  • Every time toolOutput changes, we calls fetchTasks() to update the App state with new data. This is not the effective solution but the simplest solution to demostrate the communication between ChatGPT and the App.
• If not (e.g., you’re running locally in a dev browser), it just sets toolOutput = null.

Now test it again, you will see the App will reflect new state after the tool run successfully.

If you want to send follow up message to ChatGPT when you do some action in your app, you can use window.openai.sendFollowupMessage to send a message into the conversation. For example, in your client/src/App.jsx

  const addTask = async () => {
    // The existed code
    await window.openai.sendFollowUpMessage({
      prompt: `I just added a task to the todo list: ${text}.`,
    });
  };

Other than that, you can also call tool from your app, for example:

  const addTask = async () => {
    if (window.openai) {
      await window.openai.callTool("createTask", { text });
      await window.openai.sendFollowUpMessage({
        prompt: `I just added a task to the todo list: ${text}.`,
      });
    } else {
      await fetch("http://localhost:3000/tasks", {
        method: "POST",
        headers: { "Content-Type": "application/json" },
        body: JSON.stringify({ text }),
      });
      await fetchTasks();
    }
    setText("");
  };

In order to call a tool from your app, you need to tell ChatGPT about that through the MCP tool meta by declaring openai/widgetAccessible: true when registering the tool.

 server.registerTool('createTask', {
    _meta: {
      "openai/outputTemplate": "ui://widget/chatgpt-app-todo.html",
      "openai/toolInvocation/invoking": "Creating task...",
      "openai/toolInvocation/invoked": "Task created",
      "openai/widgetAccessible": true
    },
}, ({ text }) => {
    // Your logic
})

Summary

The technology stack behind a ChatGPT App isn’t particularly new or mysterious. It builds on ideas that web developers have been using for years:

• When ChatGPT shows your app, it’s really just embedding an iframe. That means your UI can be built with any web frontend technology such as React, Vue, Svelte, or even plain HTML, CSS, and JavaScript. There’s no special rendering engine or magic framework. It’s just a secure sandboxed web page.
• Inside that iframe, ChatGPT exposes a global object called window.openai. This is how your App and ChatGPT talk to each other:
  • ChatGPT injects tool output and widget state into your app.
  • Your app can send updates or trigger actions using APIs.
• On the backend, ChatGPT communicates with your server using the Model Context Protocol (MCP). MCP is an open protocol that defines how ChatGPT can discover, call, and receive data from your app. You register tools and resources on your server, and ChatGPT calls them over HTTP (or WebSocket) using JSON messages.

All of this is still in beta and currently limited to developer access. OpenAI has said that app submissions will open later in the year, so the SDK and MCP specifications for ChatGPT App are still evolving. So we should expect changes in APIs, event naming, and configuration formats as development continues.

The sample code of this tutorial can be find on my Github.

My goal with this test wasn’t to cover every possible case or measure the model’s intelligence. I just wanted to try a few real-world tasks that I deal with in my day-to-day work, and see how the models do in terms of code quality, speed, and output. This is purely a personal experiment, not an academic or comprehensive benchmark. You might see it differently, and that’s fine, I just want to give you a quick snapshot before you run your own tests.

I decided to test two key aspects of a developer’s workflow:

• Generating code for a new feature from scratch
• Generating a test suite for an existing function

I put three of the top coding models to the test: Anthropic’s new Claude Sonnet 4.5, OpenAI’s GPT-5 Codex, and xAI’s Grok Code Fast 1.

Test 1: Generating a New App

For the first test, I wanted to see how well each model could handle a greenfield project, a common starting point for any new idea.

The Prompt

“Generate a complete, production-ready React application using Vite and Tailwind CSS. The application should be a responsive image gallery. It should fetch images from a placeholder API (like picsum.photos), display them in a grid, and open a larger view in a modal when an image is clicked. Include basic styling for a clean, modern look and feel. Structure the code into logical components and provide instructions for running the project.”

Impression

Claude Sonnet 4.5

• This was impressively fast, completing the entire task in about a minute. It presented a clean, clear to-do list that was easy for an engineer to follow.
• It was built with JavaScript and JSX, ran perfectly on the first try, styling was ok.
• The code structure and component splitting were clean, simple, and exactly what I was looking for.
• It even included a dark mode, which I hadn’t requested.
• This was my favorite output of the three.

GPT-5 Codex

• This model took a more methodical, but much slower approach. The process required me to manually confirm a series of scaffolding CLI commands, and the whole task took about a few minutes.
• The final app also use JavaScript and JSX, it was fully functional on the first try.
• The styling was better than Claude Sonnet 4.5‘s.
• It also added an infinity scrolling feature I didn’t ask for, which was great.
• While the code structure was good, it felt a bit overcomplicated for my simple request.
• The output was high-quality, but the process was a bit cumbersome.

Grok Code Fast 1

• The experience here was similar to GPT-5 Codex, taking a few minutes to complete.
• The app, which it generated using TypeScript, did start on the first try, but the functionality was broken and the CSS was messy.
• The code structure and component splitting weren’t good, and I was not a fan of the code it generated.
• The cost is significantly lower compared to the other models.

Output

Claude Sonnet 4.5

GPT-5 Codex

Grok Code Fast 1

Output: Main screen

Output: Image modal

Could not work as expected

Detail comparision

Generated Todo list

Claude Sonnet 4.5

GPT-5 Codex

Grok Code Fast 1

Claude Sonnet 4.5 delivers the most concise and focused plan.

• Aligned tightly with the prompt, it sticks to the core requirements.
• Structured around three main components: ImageCard, ImageModal, and ImageGallery.
• Smartly groups related tasks (ex: building the gallery and API integration together).
• No unnecessary features or extra technologies.
• Easiest to read at a glance, with a straight path to the final output.

GPT-5 Codex offers the most feature-rich, production-oriented approach.

• Goes beyond the prompt by adding pagination, loading/empty states, and polished styling.
• Considers usability with keyboard/escape support.
• Separates logic via an image fetch hook and types, showing modern React best practices.
• Treats the task more like building a complete webpage than just a component set.

Grok-code-fast-1 is the most detailed and step-by-step.

• Breaks everything into 10 small tasks, covering setup and functionality separately.
• Explicitly chooses Vite + React + TypeScript from the start.
• Translate the prompt into coding actions.

At this stage, GPT-5 Codex is the most thoughtful, though it also introduces more complexity in the implementation.

If I had to choose, Claude Sonnet 4.5 best matches my preferred style of working. Grok Code Fast 1 provides a clear step-by-step setup, but lacks an overall implementation structure.

Folder structure & components breakdown

Claude Sonnet 4.5‘s structure is the simplest and most direct of the three. It’s a classic JavaScript-based React project.

• It created three components: ImageCard.jsx, ImageGallery.jsx, and ImageModal.jsx. Simple and good enough structure.
• It created ImageGallery.jsx as a “container” component to manage the layout of the image cards, which is a good structure.

GPT-5 Codex‘s structure is the most sophisticated and demonstrates an understanding of advanced React patterns for building larger, more complex applications.

• It created a hooks folder containing a custom hook: useImageFeed.js. It separates the application’s logic (like fetching data, managing state, etc.) from the UI components. This makes the logic and the components easier to test and reuse.
• The components directory is much more detailed.

Grok Code Fast 1‘s structure is clean and modern for TypeScript & React development.

• The components folder contains two core UI pieces: ImageCard.tsx and Modal.tsx. This is a common way to organize UI elements.
• The core logic is likely bundled within App.tsx, making it less modular.
• The structure is less organized and clean compared to the others.

After reviewing the code, I found that the structure from GPT-5 Codex is robust enough for a production environment.

In contrast, the code from Claude Sonnet 4.5 is simple and clean, making it an excellent starting point for a developer. I wasn’t a fan of the structure from Grok Code Fast 1 in this test.

I’d consider it a tie between GPT-5 Codex and Claude Sonnet 4.5, as they both excel in different areas.

Line of Code

Claude Sonnet 4.5

• Implementation is leaner than GPT-5 Codex but heavier than Grok Code Fast 1.
• Best documentation coverage.
• It makes me feel a balance between implementation and documentation.

GPT-5 Codex

• Heaviest on real application logic, so we can understand that it is the most feature-rich implementation.
• Docs are light.

Grok Code Fast 1

• Much lighter real app logic compared to GPT-5 Codex and Claude Sonnet 4.5, explain why the functionalities didn’t work.
• Docs are better than Codex.

In summary, both GPT-5 Codex and Claude Sonnet 4.5 performed well in this test.

Personally, I value speed and simplicity, so I’d choose Claude Sonnet 4.5 for execution. However, for the planning phase, I’d lean on GPT-5 Codex because of its thoroughness.

Test 2: Writing Tests

For the second test, I wanted to see how each model would handle writing tests for a function, the kind of everyday task engineers deal with regularly.

The Prompt

Generate a Jest test suite with edge cases for this function. Put the file in a util folder.

function divide(a, b) { return a / b; }

Results

Claude Sonnet 4.5

GPT-5 Codex

Grok Code Fast 1

Claude Sonnet 4.5

• Fast to generate the test script and asked about the test setup.
• After completing the test setup, it auto ran and double-checked coverage.
• Produced 23 test cases covering division by zero, floats, negatives, and large numbers. Very detailed and thorough.
  • Covers all from Codex + Grok
  • Adds more categories:
    • Floating point division
    • Edge cases with overflow
    • Type coercion edge cases (numeric strings, booleans, null, undefined)
• Limitations:
  • More verbose, harder to maintain.
  • Some cases may be unrealistic for real-world usage.

GPT-5 Codex

• Quick and direct, produced 8 test cases.
  • Positive/negative integers
  • Fractional results
  • Division by zero (Infinity, -Infinity, NaN)
  • Special handling with Infinity numerator
  • Zero result with Infinity denominator
• Asked about setup but didn’t check coverage.
• Got the basics right, but shallow.
• Style is concise, direct, and structured, ensuring correctness without redundancy.
• Coverage is ok, but scope is narrower compared to the other two models.
• May miss some rare edge cases like non-numeric inputs or type coercion.

Grok Code Fast 1:

• Slower, required setup commands first, similar to the first test. I need to manually approve a lot of CLI commands to do the test setup.
• The good thing is that it only needs 1 prompt to complete everything, from setup to generating test cases.
• Ended with 12 test cases. Solid coverage but no coverage check.
  • Very large numbers
  • Very small numbers
  • Floating point precision issues
  • Boundary values
  • Non-numeric inputs
  • Special numeric values (NaN, Infinity, etc.)
• Organized in a clean scenario-driven approach, making it easy to reason about what’s tested, covering realistic as well as edge inputs.

Personally, Grok Code Fast 1 offers the most practical suite for production use.

GPT-5 Codex is ideal for a lean starting point, and Claude Sonnet 4.5 is best when maximum safety and completeness are required.

Cost Comparison

Here’s how the three providers price their coding models (per million tokens):

(Prices are not 100% exact; they vary depending on provider updates. You can check the latest on OpenRouter)

If cost is the biggest factor, I would consider Grok Code Fast 1, but the way I prompt will be significantly different and cost more effort.

Conclusion

After spending a good amount of time with these models, I have a clear favorite for my day-to-day coding work: Claude Sonnet 4.5. Honestly, it’s my top recommendation.

Now, if you’re trying to find a balance between cost and quality, GPT-5 Codex is a good choice. The code it writes is really polished and high-quality, and it’s more affordable to run.

But here’s the biggest takeaway for me: you don’t have to choose just one. A hybrid workflow seems like the real power.

• You could use GPT-5 Codex for the initial planning phase, since it’s so thoughtful about architecture.
• Then, when it’s time to actually write the code, switch over to Claude Sonnet 4.5 to take advantage of its raw speed and incredible thoroughness.
• And even though Claude Sonnet 4.5 generates the most comprehensive test cases, Grok Code Fast 1 felt more practical for production use, so when it comes to writing tests, Grok is not a bad choice.

I’m glad we could dive into this together. I’m really interested to hear about your own experiences as you get to know these tools!

It’s a question I hear a lot, and I love it. It shows a desire to grow beyond just shipping tickets. The official documents are great for defining expectations, but they can feel like a checklist. The real journey isn’t about ticking boxes.

In the previous post, I shared about the real stages of experience in Software Engineering, so that you know what you should focus on to gain more experience. In this post, I will follow up on another aspect of what type of problem you should focus on to grow.

After years of building teams and mentoring engineers, I’ve found that the entire arc of a technical career can be distilled into a single idea:

Your growth is a journey from solving clearly defined problems, to navigating highly ambiguous problems, to finally identifying the right problems to solve for the business.

That’s it. That’s the game. You move from being given a map, to being given a compass and a destination, to being the one who decides which mountains are worth climbing in the first place.

While every company has its own matrix, here’s how I see that journey break down in practice.

Stage 1: Building the Foundation

This is where it all starts. Your title will be Software Engineer. The focus is on execution, reliability, and learning the craft. In this stage, I will split it into 2 phases.

Software Engineer (Phase 1): You deliver well-defined tasks on time and with high quality. You’re handed a clear spec, and you can be trusted to build it with minimal guidance. You’re honing your technical skills and proving your dependability.

Software Engineer (Phase 2): You don’t just take tasks, you clarify them. You spot the missing edge cases in a ticket before you start coding. You collaborate with your peers to complete assignments, asking the right questions to make the work better. You’re moving from a pure doer to a participant in the solution.

Stage 2: Expanding Your Scope

This is the most significant transition for many. Your title will be Senior Software Engineer. You begin to shift from owning tickets to owning outcomes. In this stage, I will also split it into 2 phases.

Senior Software Engineer (Phase 1): You own an entire project. Instead of a series of tasks, you’re given a goal, like “Improve the checkout flow”. You are responsible for clarifying the scope, breaking down the work, and collaborating across the team to deliver it. You’re now a leader of execution.

Senior Software Engineer (Phase 2): You’ve moved beyond project-level problems to team-level problems. You see the friction in the deployment process and propose a solution. You notice the team is struggling with a legacy component, and you create a plan to address it. You guide the team to a better way of working.

Stage 3: Scaling Your Impact

At this stage, your primary role is no longer only writing code, it’s creating leverage. You enable everyone around you to be more effective. Your title will be Staff Software Engineer, to Senior Staff Software Engineer, to Principal Software Engineer, to whatever your organization has.

Staff Software Engineer: You are the go-to expert in a specific domain. When a hard problem involving your specialty comes up, you’re the person everyone seeks out. You provide direction, mentor others, and multiply your impact by enabling the entire team to succeed within your specialty.

Senior Staff Software Engineer: You take on fuzzy, organization-level problems. The challenge might be “Our web performance is degrading” or “We need a unified design system”. You coordinate across multiple teams, create the plan, and ensure the entire org can deliver on a complex, high-impact outcome.

Principal Software Engineer: You operate at the highest level of technical strategy. You aren’t just solving problems; you are identifying the most important future challenges and opportunities for the entire engineering organization. You see what’s three years out, propose a clear vision, and lead efforts across the company to make it a reality.

Important Truths

First, each level builds directly on the skills of the one before it. You can’t be an effective Senior Software Engineer who owns projects if you haven’t first proven you can deliver tasks reliably. This growth has to be demonstrated consistently, not just on one showcase project. I also mentioned once in the post Mindset > Title, in order to move to the next level, it is not about changing the title. Promotions aren’t about potential alone. They’re about demonstrating the consistent behavior, attitude, and mindset aligned with the next role.

Second, you don’t have to keep climbing**.** In my experience, and as far as I know from different organizations, from Senior Software Engineer at stage 2 and above, it is considered a “career level”. This means if you are happy and effective in that role, you can remain there for the rest of your career. The pressure to advance is primarily on the earlier levels. Finding a position where you can deliver high value and feel fulfilled is a win, not a failure.

I hope this perspective helps clarify what real growth looks like. Now, the question is back to you.

Are you consistently meeting the expectations of your current level? And ready to start operating at the next one?

In software engineering, experience isn’t just about how many years you’ve been in the game. I talked a bit about this in my previous post on The Quiet Power of Pattern Matching. Real experience shows in how you tackle problems, build solutions, and turn ideas into something that actually works.

Personally, I find it useful to think of experience in three broad stages: engineers with no experience, engineers with some experience, and engineers with extensive experience.

When you have a clear sense of which stage you’re in, it’s much easier to know what to work on next. It gives you direction and helps you grow faster by setting goals that actually match where you are right now.

Engineers with no experience

This is the stage where theory hits the real world.

Most beginners come in fresh, maybe from university, a coding bootcamp, or an online course. They’ve spent a lot of time absorbing ideas about how things should work, learning stuff like design patterns, clean code, best practices, and system architecture.

But knowing the theory is one thing. Putting it into practice is a whole different story.

And it’s totally normal to struggle here. Turning concepts into working code can feel overwhelming. You’ll make mistakes, probably a lot of them. That’s not the problem. The real problem is not learning from those mistakes.

At this stage, the goal is to learn fast. Figure out what went wrong, why it happened, and how to avoid doing it again next time.

Engineers with no experience will learn the paths that lead to mistakes and use this knowledge to prevent future errors.

Engineers with some experience

This is the stage where you need to build your experience bank.

Engineers with some experience have moved beyond theory and into the hands-on world of real projects. They’ve dealt with actual problems, started to notice recurring patterns, and built confidence in getting things done.

At this point, they’re pretty good at solving problems, but they might not always see the curveballs coming.

Foresight is still a work in progress. This stage is all about stacking up more experience, trying things, breaking things, fixing them, and learning along the way. It’s not just about avoiding mistakes they’ve made before, but also starting to spot and prevent the ones they haven’t seen yet.

Engineers with some experience can identify not only the paths that led to their own mistakes but also predict other paths that might lead to similar issues, allowing them to prevent a broader range of mistakes.

Engineers with extensive experience

This is the stage where you will think more about anticipating and preventing mistakes from happening.

What really sets experienced engineers apart is their ability to see problems before they happen. They’ve been through enough projects, some smooth, some rough, to build a kind of mental model of what works and what doesn’t. That instinct helps them avoid a lot of unnecessary pain, not just for themselves, but for the whole team.

But it’s not just about being good at solving problems. Extensively experienced engineers tend to take a step further. They guide others, spot patterns early, and help the team stay out of common traps. They’re always looking for better ways to do things. They ask questions like “Is there a simpler way to do this?”, “How can we do this better?”, etc.

Eventually, they move from just reacting to the issues to building systems that prevent the issues in the first place. They have a deep understanding of best practices and help embed them into the team’s habits. They know that building great systems isn’t a solo effort. It takes trust, collaboration, and a shared mindset of learning and growing together. That mindset doesn’t just improve the code, it helps to shift how the whole team thinks and solve problems.

Engineers with extensive experience can foresee potential issues from the starting point and implement strategies to prevent mistakes from occurring in the first place.

For leaders, this perspective allows you to better support your team. You can set the right expectations, give more targeted feedback, and offer opportunities that match each person’s level. It also helps you spot potential early and grow your people in the right direction.

For individual contributors, knowing where you are helps you focus. You can double down on the skills that matter most right now, instead of trying to learn everything at once. You’ll also be better equipped to ask for the right kind of support, take on suitable challenges, and track your own progress.

When everyone understands their stage and what comes next, the team grows together with clarity, purpose, and momentum.