My AI Development Workflow After Two Months at a Big Tech Company

Background

This all started with a few one-on-ones with my team lead. He was quite interested in how I use AI tools, build my personal Harness, and structure my AI coding workflow. Part of the reason is that I’ve been delivering features quickly and well, and I’ve become the main owner on some projects. So I took this opportunity to put together my daily AI workflow. Right now, I mainly do Agent development on the team while also maintaining existing backend services.

I previously shared a similar workflow on Xiaohongshu (RED). Back then, the context was that GPT-5.4 and Opus 4.6 were already capable of completing tasks well, provided they had accurate context and reasonable constraints. The rise of Harness Engineering also helped everyone realize that adding constraints can help you better steer powerful models.

For example, Skills like Superpowers offer a fairly heavyweight implementation centered around Spec and TDD, making it easier for people to organize and advance tasks.

But there are downsides to this approach. The most noticeable issue is that tokens burn through quickly. Skills like Superpowers contain many workflows designed to constrain the model’s next steps. Even when a step is globally unnecessary — say, the context is sufficient and implementation could start immediately — the model may still follow the prescribed flow.

With new model releases, I’ve seen many developers start sharing that they’ve largely dropped these heavyweight Skills. A major reason is that as models improve, constraints and processes we once found helpful are becoming noise for the model. For instance, when OpenAI released Astra, they specifically wrote a blog post about how to clean up unnecessary Skills and system prompts to improve the model experience.

So, this article combines my practice over the past few months to share approaches that work well for me, and to discuss how to make better use of various Agents to improve day-to-day development efficiency.

1. The Skills and Prompts I Commonly Use

My Current Tool Breakdown

Right now, I mainly use Codex + GPT-5.6 Sol for coding and implementation, and Astra for planning. Before Astra was released, planning was primarily handled by GPT-5.6 Sol Max.

For simple requirements, I use pi + DeepSeek V4 Flash to implement. Adversarial review of designs and code review are mainly handled by Claude 5 Fable. For personal projects, I also use web-based GPT-6 Pro for primary design work.

Skills I Commonly Use

• think: tw93’s Skill, mainly used for design alignment and brainstorming.

• grill me / grill with docs: Mainly used for requirement clarification. Through successive follow-up questions, it works out goals, constraints, and trade-offs clearly, then captures them into an ADR or CONTEXT.md as needed by the development process. It helps surface issues that weren’t considered during initial alignment.

• implement: Used in conjunction with grill, part of Matt Pocock’s Skills suite, for implementing well-defined plans or Issues.

• ponytail: Used to clean up AI over-engineering, making review easier. I use this frequently because GPT-5.6 Sol tends to over-engineer in many cases.

• handoff: Organizes current context into a file for continuing tasks in a new session. I typically use it to hand off from Codex to Claude Code or pi agent.

• check: Used for code review, typically when submitting an MR.

• Skills accumulated from work and personal development: mainly reusable process SOPs, such as end-to-end testing. My suggestion is that if a process repeats more than three times in your daily work, consider having Codex turn it into a Skill for future reuse.

Prompts I Commonly Use

I rarely write long prompts by hand anymore. When I need one, I usually have Codex put it together. For example, after multiple rounds of discussion, if I want to hand the current context over to GPT Pro for design work, I’ll have Codex first generate a complete handoff prompt.

Beyond that, I frequently use the following types of short prompts.

Sometimes they achieve the effect of “one sentence worth thousands.” I think of them as “mental shortcuts” for the model.

They’re not magic spells — they’re highly standardized methodologies in human knowledge. Models have seen vast amounts of related papers, code, design documents, and discussions during training, so often, you don’t need to hand-write hundreds of lines of workflow — you just tell it which mode of thinking to adopt. Below are prompts I’ve found particularly effective in my own practice:

• First Principles: Don’t keep optimizing along the existing approach. Re-examine what the problem actually is and how it should be solved. For example, if an API is slow, you could say:

Don’t continue designing around the predetermined “add a Redis cache” approach. Analyze from first principles why this API is slow, and identify the minimal necessary solution.

The model’s focus shifts from “how should Redis be designed” to:

Where exactly is the bottleneck — SQL, network, serialization, lock contention, or redundant computation? If adding an index to the SQL solves it, why introduce Redis at all?

This type of prompt works well when you suspect “the question itself might be wrong.”

• Adversarial Review: Don’t help me find reasons to justify my approach — try to prove it’s wrong.

The ordinary way to ask is:

Help me check if there are any problems with this technical design.

Instead, try:

Do an adversarial review of this design, prioritizing the search for counterexamples that could overturn the core assumptions.

If your design is “introduce a distributed lock to solve duplicate requests,” the model won’t just tell you how to set the lock timeout — it’ll start pushing back:

Do duplicate requests really need mutual exclusion? Can idempotency solve this? What happens if the lock service goes down? What if the lock expires but the business logic hasn’t finished? Are you introducing a new distributed point of failure just to solve a local problem?

This type of prompt is especially useful for design reviews and code review.

• Ablation Studies: The system improved, but that doesn’t mean everything you added was useful.

For example, if you made three optimizations at once:

After adding an index, a Redis cache, and batch queries, API latency dropped from 800ms to 100ms.

You can directly ask:

Design ablation experiments for these three optimizations to determine where the actual gains come from.

The model will design controlled comparisons around different combinations — starting from baseline, comparing index only, index + cache, index + cache + batch queries, and so on.

You might ultimately discover:

The index alone reduced latency from 800ms to 120ms; the other two complex solutions only contributed the remaining 20ms.

Now you know more clearly which code is worth keeping and which complexity might be unnecessary.

• Occam’s Razor: When outcomes are comparable, prefer the solution with fewer assumptions and lower complexity.

For example, if an Agent designs something like this for you:

Kafka + Redis + Distributed Lock + State Machine + Scheduled Compensation.

You can add:

Re-review this design using Occam’s razor. Remove all non-essential mechanisms while still meeting the requirements.

Often, it will discover:

In the current scenario with single-database writes, a transaction plus a unique index is sufficient.

This is especially useful for current coding Agents because models tend to over-engineer in pursuit of “completeness.”

• High Cohesion, Low Coupling: Re-examine code responsibilities and boundaries.

For example, if you find that an OrderService has grown to 2,000 lines, you can ask:

Review the responsibility boundaries of OrderService according to the principles of high cohesion and low coupling, but don’t split things apart just for the sake of splitting.

The model will typically start examining:

Why does the order service handle inventory, coupons, SMS, payments, and reporting all at once? Which logic belongs to the order domain itself, and which should be handed to other modules through stable interfaces?

What this activates isn’t just simple “file splitting” — it’s an entire framework for judging modularity, information hiding, dependency direction, and separation of responsibilities.

So I rarely write things like:

Step 1: Analyze requirements. Step 2: Check assumptions. Step 3: Look for alternatives. Step 4: …

Many mature methodologies are already something the model has learned. I prefer to just tell it:

Re-analyze from first principles. Do an adversarial review of the current approach. The core mechanism must be validated through ablation studies. The design should follow Occam’s razor. The code should maintain high cohesion and low coupling.

Behind these few dozen words, five distinct cognitive actions are specified:

Redefine the problem → Attack the assumptions → Validate the contribution → Remove the complexity → Organize the system boundaries.

This is what I see as a shift in prompt engineering for the new model era: rather than hard-coding a complete thought process for the model, use accurate methodologies to tell it “how to think,” then add the constraints that are truly necessary for the current task.

2. My Daily Development Workflow

When I pick up a requirement, I first hand over the relevant context to the Agent — PRDs, meeting notes, chat logs, and user feedback — then use grill to do requirement alignment with it.

These materials are often not a single, consistent set of requirements. The PRD may be outdated, meeting discussions may have added constraints, and chat conversations may have changed priorities. My own understanding of the requirement may also contain unstated assumptions.

I have the Agent combine the team wiki and existing codebase to understand these materials, then use successive follow-up questions to clarify goals, boundaries, and trade-offs that will affect implementation. Some questions I can answer on the spot; others require going back to product managers or relevant teammates to confirm.

Here, I maintain a threshold: when the remaining questions won’t significantly change the implementation direction or acceptance outcomes, it’s time to start development.

I don’t require it to plan every implementation detail upfront — otherwise, requirement alignment itself becomes a heavyweight process.

The aligned conclusions are captured into a Spec or CONTEXT.md, mainly documenting the problem to be solved, scope, key decisions, and acceptance criteria for this task. This also makes it convenient for the implementing and reviewing Agents to share the same context without re-reading the entire conversation.

Once the design is settled, I let the main Agent decide how to execute based on task complexity. Simple requirements get implemented directly; complex ones are broken into Issues with clear boundaries and independently verifiable outcomes. Only parts that can truly proceed independently are handed to subagents for parallel development in separate worktrees, with the main Agent handling integration.

The coding Agent writes tests first. Once it believes the work is ready for delivery, I introduce additional Agents for cross-adversarial review depending on task complexity. All issues found are fed back to the main coding Agent — Codex — for fixes and re-verification.

Before I do my own review, I run end-to-end tests.

I no longer read all generated code line by line. I mainly look at test results and core business logic. There’s a critical prerequisite for this: every MR must be small enough in scope, and the full business path should be progressively verified as development advances.

Small MRs keep each change I need to understand and evaluate manageable; end-to-end tests help me verify that these changes actually work within the real business flow. During human review, I focus on confirming business logic and whether existing test results are sufficient to support this delivery.

3. Building Agent-Friendly End-to-End Tests

AI is already very good at writing test cases — it’ll write hundreds of lines of tests for a simple bugfix (especially 5.6 Sol). More tests aren’t inherently a problem, but we still encounter unexpected errors after deployment.

In my practice, a core issue is: we haven’t provided Agents with an end-to-end testing environment where they can discover these problems during coding and self-testing.

If we can set up such an environment — letting Agents conveniently execute tasks through the real entry points in the test environment and verify all the way through to the user-facing outcomes — we can feel much more confident running AI-generated code in production systems.

In actual development, I’ve built an end-to-end development testing environment for our business. Agents can easily query database tables, check logs, and connect to machines for troubleshooting.

The entire setup process essentially involves having the Agent distill my daily self-testing workflow, consolidating scattered tools and capabilities: things that can be tooled become MCPs or CLIs; reusable processes become Skills.

This does require upfront effort, but don’t be discouraged. Once built, it significantly speeds up development, reduces rework and the risk of production issues, and you don’t have to worry all day about whether AI-generated code will cause incidents.

Around Agent-friendly end-to-end testing, I’ve primarily done four things:

• Help the Agent get familiar with the environment: Support one-click startup of the test environment, test data creation, clear documentation of the current version, test accounts, and permissions, plus cleanup and reset capabilities.

• Enable the Agent to operate the business system: Execute real business flows through browser, API, or CLI.

• Make it easy for the Agent to query databases and logs: Use a read-only database MCP to verify persisted results, and use log system Skills and trace queries to check request paths and locate issues.

• Reuse tedious but stable workflows: Write stable operations as scripts, and organize entry points and troubleshooting methods into Skills, reducing repetitive manual intervention and back-and-forth.

On top of this, let me share a few approaches I’ve found particularly effective.

• Browser Automation: When a business system requires browser interaction, I recommend the open-source browser ego lite. It’s convenient and fast. Paired with pi agent + DeepSeek V4 Flash, you can run through tests relatively quickly, reducing testing time.

• Wrap operations into a unified CLI: Integrate reusable Skills, configured MCPs, and scripts into a unified testing CLI that provides capabilities for environment checks, data preparation, scenario execution, result queries, and cleanup. This can also become an internal efficiency tool. I’ve already built this into a CLI, and it’s very handy for day-to-day troubleshooting.

• Make tools directly serve acceptance criteria: DB queries confirm state, logs and traces explain failures, but expected results must always come from business contracts. The Agent must not determine correctness based on what the system returns. Under complex business logic, the system can absolutely return a result that looks reasonable but doesn’t actually meet the requirements. Tools help us gather evidence; they don’t define the right answer for us.

• When the product itself is an Agent, also check answer quality: If the product being tested is itself an Agent, beyond whether the business flow works, you also need to consider answer quality. This is what we often call Agent Eval — I won’t go into detail here.

4. How to Review AI-Generated Code

We’ve covered how to get AI to write high-quality code, but ultimately, the developer remains the first responsible party for business requirements.

Without review, things can go wrong quickly in large systems.

And you probably don’t want to be woken up in the middle of the night for an on-call incident, only to discover the root cause was AI-written code.

Here are my main practices for review:

• Look at acceptance criteria first, then test results: First check the acceptance criteria the Agent provided, then compare against the end-to-end test results to confirm whether expectations are met and nothing is missing. Don’t just look at how many tests passed — check whether those tests actually verify what this requirement cares about.

• Follow the business path through the implementation, and focus energy on high-risk areas: I concentrate on permissions, state transitions, concurrency, retries, data consistency, migrations, and rollbacks — the high-risk parts. For stable CRUD patterns, I spend less time — in fact, I don’t even look at those anymore.

• Specifically inspect new abstractions and mechanisms: For new abstractions and mechanisms, I use an Occam’s razor mindset to have AI help me review them again: Are they truly necessary? Is there a simpler implementation? Have they introduced too much complexity to solve a local problem?

• When there are many MRs, consider building a dedicated Review Bot: If your team has a high volume of MRs, you can design a dedicated Review Bot to handle cross-review. Unlike directly calling pi agent / Claude Code for adversarial review, this emphasizes combining Git change information with pre-designed review workflows to create a repeatable review capability specifically for MRs.

5. Summary and Reflections

My most obvious bottleneck right now is review speed.

An Agents can work on several tasks simultaneously, but my ability to understand business context, evaluate designs, and confirm delivery doesn’t multiply at the same rate. If all I do is let it write more, the result is likely just a larger backlog of code waiting for review.

So what I want to improve next is having recurring issues caught and fixed before they reach me.

Issues that can be caught through type checking, tests, and business assertions should be handled by the Agent during development as much as possible. What needs my judgment should be focused on: whether the requirements were understood correctly, whether the core business logic holds, and what unverified risks remain in this change.

A dedicated Review Bot can help with this, but its value should be measured by how well it reduces missed real issues and manual effort — not by how many comments it posts.

This has also made my understanding of Harness more concrete: besides giving the Agent the right context, you also need to give it an environment where it can execute tasks and criteria for judging results.

I’ve consolidated the operations I repeatedly do during daily self-testing into CLIs, scripts, and Skills, letting the Agent run the system itself, check results, and find evidence of failures. For similar tasks in the future, these capabilities can be reused, and gradually shared with other teammates.

At the same time, this workflow also needs regular subtraction.

Some steps exist to compensate for the shortcomings of a particular model generation. When the model changes, we should re-evaluate whether those steps still provide value. Simple tasks can be done directly; complex tasks can add planning, decomposition, and cross-review. For example, after Astra was updated, I removed some overly strict constraints from AGENTS.md. The model iterates, and our workflows need to iterate with it.

Of course, testing and review reduce uncertainty, but humans still need to provide the correct acceptance criteria. Even if the code and tests align with each other, they might have misunderstood the requirement together. End-to-end tests only cover behavior in the selected environment and scenarios; production traffic, concurrency, and data distribution can still introduce new problems.

For a developer relatively early in my career like myself, I still very much want to learn more domain expertise through work. However, AI has indeed reduced some opportunities to learn by getting burned. Some valuable experiences that would have come from encountering problems and debugging them firsthand may now be reduced to an AI’s:

“I was wrong. Let me fix it.”

So,

I now reserve part of my daily development time for learning and reflection, while also thinking about: what capabilities do R&D engineers truly need in the AI era?

This article captures the approach I’ve gradually developed over my first few months on the job within my own business domain. I’m still exploring its applicability and limitations.

I’d suggest picking the most common self-testing path you work with, trying to let an Agent run through it independently and capture evidence, then solidifying the effective steps into reusable assets.

Due to company confidentiality requirements, many details can’t be expanded here. I hope this article serves as a starting point, and I’d love to hear about good practices from your own development work~