From Plan to Action

In our previous lessons, we learned how to create a high-level technical plan. This plan acts as our map. Now, we are ready to move from planning to building. Our goal is to add a comments feature to our task management app. This feature allows users to add comments to tasks, see a list of comments, and delete their own comments.

If we ask an AI like Codex to "Build the whole comment system," it might get overwhelmed and make mistakes. Instead, we take our technical plan and break it into small, executable steps. This ensures that the code is high-quality and easy to test.

In the CodeSignal IDE, you will find that the libraries we use, like SQLAlchemy for databases and Pytest for testing, are already installed. You can focus entirely on the logic of building your feature.

Decomposing the Comments Feature

To build a feature successfully, we group our work into logical phases. We call these atomic tasks. A task is atomic if it focuses on one thing, affects only a few files, and can be finished in one sitting — usually in under 2 hours.

For our comments feature, we split the work like this:

PhaseTask IDFocusDependencies
FoundationT001, T002database model and repositoryNone
Business LogicT003, T004services and validation schemasT001, T002
API LayerT005, T006endpoints and authorizationT003, T004
IntegrationT007Final end-to-end testsAll previous
Defining Task Requirements (The Template)

Every task needs a clear set of instructions so that Codex knows exactly what "done" looks like. We use a standard template for this. Let's look at the requirements for our first task, T001.

Task Template: [T001] Create Comment Model

  • Files Modified: src/models/comment.py, tests/unit/test_comment_model.py.
  • acceptance criteria:
    • Model defined as a SQLAlchemy declarative model with proper Python type hints.
    • Fields: id (Integer, primary key), task_id (Integer, Foreign Key), author_id (Integer, Foreign Key), content (String), created_at (DateTime).
    • Relationships: task (to Task model), (to model).
The Test-First Workflow with Codex

When you start a task with Codex, you should use a test-first workflow. This means we ask Codex to write the test before the actual code. This ensures that the code actually does what we want.

Let's walk through how you would prompt Codex for T001.

Step 1: The Initial Prompt You tell Codex: "Create the Comment model following the T001 acceptance criteria. Write the tests first, verify they fail, then implement the model, and verify they pass."

Step 2: Writing the Failing Test Codex will first create a test file. Since the Comment model does not exist yet, the test will fail.

When Codex runs this test, the output will look like this:

Step 3: Implementing the Model Now Codex writes the actual code to make the test pass, following the exact patterns used in this project.

Recognizing and Recovering from Task Bloat

Sometimes, we accidentally make a task too big. This is called task bloat. Imagine trying to combine "Create validation schemas" and "Create API endpoints" into one single task.

The Failure Mode: If a task touches 4 or 5 files and has 12 different acceptance criteria, Codex might lose focus. It might generate incomplete tests or forget to add validation. You will notice this if the test coverage is low or if Codex starts hallucinating (writing code that does not exist).

The Recovery: If you see Codex getting confused, stop! This is a signal to split the task.

  1. Stop the current execution.
  2. Split the bloated task into two smaller tasks:
    • T004: Comment validation schemas with Pydantic (2 files, 45 mins).
    • T005: API endpoints with FastAPI (2 files, 60 mins).
  3. Execute them one by one.

By splitting the work, Codex can focus 100% on the validation schemas first and then 100% on the API . This leads to significantly better results.

Summary and Practice Prep

In this lesson, we moved from high-level planning to understanding the execution methodology. Here are the key takeaways:

  • Decompose First: Break features into atomic tasks (T001, T002...) before writing any code.
  • Use Templates: Define clear files, acceptance criteria, and dependencies for every task.
  • Follow Patterns: Always match existing codebase conventions (Integer primary keys, SQLAlchemy model decorators, timezone-aware timestamps using default=lambda: datetime.now(timezone.utc), explicit nullable=False on required fields).
  • Test-First Workflow: Always ask Codex to write a failing test before the implementation.
  • Stay Atomic: If a task is too large, Codex will lose focus. Split it into smaller chunks to maintain quality.

In the upcoming practice exercises, you will enter the CodeSignal IDE and use Codex to execute these exact tasks. You will apply this methodology hands-on, writing tests, implementing features, and seeing them come to life in the actual TaskMaster codebase!

Sign up
Join the 1M+ learners on CodeSignal
Be a part of our community of 1M+ users who develop and demonstrate their skills on CodeSignal