Why this is not another tools list
There are hundreds of posts listing AI tools for engineers. Most describe what each tool is, not how to use them together as a coherent workflow.
The gap between "I have these tools" and "I am materially faster because of these tools" is a workflow problem. The tools are available to everyone. The workflow is what most people are still figuring out.
This is how I actually work. Not an aspiration or a sales pitch — a concrete account of a working day.
The structure
My working day breaks into three phases with distinct AI usage patterns: morning setup, active development, and synthesis/review.
Morning setup (first 30 minutes)
Before writing any code, I invest in context.
Day brief with Claude
I open a Claude session and write a structured brief for the day. This sounds ceremonial; it is not. The act of writing it forces the clarity about what I am doing and why that otherwise happens vaguely in the background throughout the day.
My brief structure:
- What I am building and where it is in its lifecycle
- What was completed yesterday and what state things are in
- Today's specific goals, ranked by priority
- Known blockers or decisions I need to make
- Constraints I want to hold throughout the day
Claude reads this and returns two things: potential risks I have not accounted for, and suggested task ordering based on dependencies. I accept some of it, ignore some of it, and often revise the brief based on what the exchange surfaces.
This takes fifteen minutes. It replaces an hour of scattered re-orientation that used to happen implicitly across the morning.
Manus research tasks queued
While I am doing the Claude brief, I queue research tasks in Manus for anything I know I will need during the day: current documentation for a library I am integrating, competitor feature analysis for a design decision I am making, benchmark data for an architectural choice.
Manus runs these in the background. By the time I start active development, the research is waiting for me.
Active development (main working hours)
Most development runs through Claude Code. The workflow is tight: task specification, implementation, review, next task.
Task specification discipline
Before each Claude Code task, I write a specification that fits one of two templates:
Implementation task: What needs to be built, what interfaces it must satisfy, what tests must pass, what files are in scope, what is explicitly out of scope.
Refactor task: What currently exists, what the target state looks like, what must not change, what the verification looks like.
The specification writing is 5-10 minutes per task. The implementation is usually correct on the first attempt. Without the specification, I spend more time reviewing and correcting than I would have spent specifying.
When I switch from Claude to Gemini
Twice or three times during a day, I hit a task that involves large input. An unfamiliar codebase I need to understand before integrating. A set of design documents I need to reconcile. A collection of API documentation for a new dependency.
These tasks go to Gemini. I paste in all the relevant material, add a framing block describing what I need, and get back synthesis that would have taken me an hour to produce manually.
The switch is intentional. I do not try to chunk this material into Claude — Gemini's handling of the full corpus is qualitatively better for synthesis tasks.
Manus for blockers
During development, I occasionally hit questions that require current web information: a library that changed after Claude's training cutoff, an error I cannot find in the documentation I have locally, a known incompatibility that others have solved and written about.
These go to Manus with a specific question. Not "research X" — "find the current documentation for [specific function] in [library] [version] and any known issues with it on [platform]."
The specificity matters. Broad Manus queries return broad results. Narrow queries return actionable ones.
The review habit
I review every Claude Code output before it enters the codebase. Every output. Not because Claude is unreliable — because I am responsible for the codebase and reviewing is how I know it.
The review is fast when the specification was good: I am checking whether the implementation matches the specification, not trying to understand what an under-specified agent produced.
Synthesis and review (last hour)
At the end of the day, I shift from production mode to synthesis mode.
End-of-day summary with Claude
I paste the day's git log — the actual commits, diffs included — into a new Claude session with a question: "Based on what was shipped today, what are the most important things to carry forward into tomorrow's context?"
The output is a summary I use as the starting point for tomorrow's brief. It takes two minutes to generate and five minutes to edit. The alternative — reconstructing what I did yesterday from scratch — takes twenty minutes and misses things.
Cross-tool synthesis with Gemini
When the Manus research from the morning produced material I need to reason about at depth — a long document, a complex set of tradeoffs — I feed it to Gemini in the evening with the context of what I decided and why.
The output is a decision record: what the research showed, what I chose, the reasons, and the things I deliberately did not consider. This becomes context for future sessions when I am asking "why was this built this way?"
What I have stopped doing manually
The list is long:
- Looking up documentation for libraries I have not used recently (Manus or Claude)
- Writing boilerplate for new files, modules, or tests (Claude Code with a good spec)
- Manually cross-referencing design documents during a refactor (Gemini)
- Reconstructing context at the start of each day (morning Claude brief)
- Explaining decisions I made to future-me (end-of-day synthesis)
These were not the interesting parts of engineering work. Eliminating them has not made the work less satisfying — it has made it more so, because more of the time is spent on the parts that require actual judgment.
The meta-lesson
The engineers I see get the most from this workflow treat the AI session design as professional craft. The brief, the specification, the synthesis request — these are not prompts. They are information transfers, and their quality determines the output quality.
The tools are fast and cheap. The quality of your thinking about what to ask is the constraint.
That is not a limitation unique to AI-assisted work. It was always true. The AI workflow just makes the causal link more visible.