The two skills that actually matter when AI writes the code

How to design better software and turn it into tasks AI agents can execute reliably.

Hey friend 👋,

Most AI coding advice you find online focuses on tools.

Which model should you use? How should you configure Claude Code? Which agent harness is best? How many plugins and MCP servers do you need?

Those things can help, but they’re no longer that important.

My coding setup is “ridiculously” simple and I don’t think you need very many skills at all when it comes to building software with AI. One thing I’ve noticed having worked with a lot of engineering teams this year is I feel people are installing way too many skills and overcomplicating everything. For example, I see people installing skills teaching agents how to use Git worktrees or “how to do test-driven development”. This is pretty ridiculous as agents already know how to do this. There’s no need to have a skill to do that.

Honestly, I think “too many skills” is becoming a new anti-pattern at this point.

Coding agents are already very good at writing code. Give a capable agent a clear task and it can implement the change, run tests, open a pull request, and respond to review feedback.

The harder work happens before the agent starts coding.

You need to decide what to build, make the important technical choices, and break the work into tasks the agent can complete reliably.

These are the two skills I think AI engineers should focus on: design and planning.

The software development process

I think about software development as five phases:

1. Design (what, why, how)

2. Planning (break work down logically)

3. Building (give tasks to agents)

4. Verification (quality checking and iteration)

5. Deploy (the thing that matters)

AI agents can now handle much of the building and deployment has been automated for a long time now.

Verification depends on what you’re building. A mission-critical system with millions of users needs more human review and testing than a small side project. But even here, agents can run automated tests, review code, check the application in a browser, and catch common problems before you look at the pull request.

That leaves design and planning as the two areas where your judgement has the most influence.

In my experience, design is what separates good software from a vibe coded app with no limits that falls over the minute it hits real users.

Design has two parts

Before writing code, I separate design into two stages.

1. Requirements

This is where you answer:

• What are we building?

• Why are we building it?

• Who is it for?

• What should the user be able to do?

• What is outside the scope of this change?

The goal is to understand the problem before choosing a solution.

2. Technical design

This is where you make decisions about:

• architecture

• APIs

• databases and data models

• authentication and permissions

• failure handling

• concurrency

• security

• limits and rate limiting

• monitoring and alerting

• testing

• rollout and deployment

These decisions are expensive to correct after implementation. This is why senior engineers spend so much time on technical design.

Agents can help you explore these questions, but you still need to make the final decisions.

I use four agent skills to move from an idea to implementation-ready tasks:

Here’s how I use them.

Step 1: Explore the feature

Don’t jump directly from an idea into a formal design document.

Start by thinking through the feature with an agent. Explain the outcome you want, then ask it to surface questions, choices, and edge cases.

You can adapt this prompt:

Help me ideate this feature before we write any code.

[Describe the feature in one or two sentences.]

Surface key decisions, choices, and considerations. 

Do not write an implementation plan yet.

Treat this as a conversation. The agent will suggest decisions you disagree with. You don’t want to accept every recommendation. You want to understand the trade-offs and choose deliberately.

Step 2: Write the technical design

Once the feature is clear, use the design skill to capture the decisions in a document.

For the feature in my video, I was building a CLI tool that watches a task board and automatically assigns suitable tasks to coding agents.

The initial idea sounded simple:

1. Watch the board for ready tasks.

2. Match each task to an agent.

3. Let the agent complete the work.

4. Update the task when finished.

The design process exposed a less obvious problem: what happens if two agents try to claim the same task at the same time?

That race condition is easy to miss if you start coding immediately. It becomes much easier to see when you map the states, responsibilities, and failure cases first.

A useful design prompt is:

Use the $design skill to write a technical design for this feature.

The important thing is to make hidden decisions and problems visible before implementation begins.

Step 3: Review the architecture

The first design is rarely the final design.

I use an architecture review skill to challenge the proposal and look for missing cases. For important work, I may also ask a different model to perform the review.

For example:

Review the design using the $architecture-review skill. Focus on what could be simplified in our design. 

If you’re going to spend more tokens anywhere in the process, spend them on design. A mistake found here is much cheaper to fix than a mistake found after the feature reaches production.

Step 4: Make the design readable

MarkDown is a great format for agents, but it can be pretty difficult to read. So one of the things I’ve been doing lately is to use the $html-doc skill to turn MarkDown designs into more human-readable HTML documents with clearer diagrams and a much nicer reading experience.

Ultimately, the goal of the design stage is to make sure you fully understand what you’re building before you hand this off to an agent.

Step 5: Break the design into tasks

Once the design has been reviewed and approved, the planning work becomes more mechanical.

Use an agent to turn the document into small, ordered tasks:

Use the $plan skill to turn this design into GitHub issues we can use to track the work. Link all the tasks to a parent issue to make it easier for me to track. 

A simple feature might fit into one task. A detailed design with several components, state changes, and failure cases should be split into smaller units.

The aim here is to give each agent enough context to succeed without overwhelming it with the entire project.

What can go wrong

This process still requires judgement.

Don’t let the agent make important product or architecture decisions without review. Don’t hand a large design to one coding agent and expect a reliable one-shot implementation. Don’t automate verification beyond the level of risk you’re comfortable accepting.

Agents are good at retaining detail and doing mechanical task breakdown. Humans are still responsible for deciding whether the proposed software should exist and whether the design makes sense.

Get the skills

I walk through this full process with a real feature in my latest video:

Watch the complete design and planning workflow.

You can also download the four skills for free.

If you want to learn these workflows alongside other developers building real software with AI, you can join the AI Engineer community.

Thanks for reading.

Have an awesome week :)