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.

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.

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.

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.

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.