Fractal Accelerator - Class 3 notes

Summary

Class 3 was about engineering as a way of thinking: how to turn an unclear problem into shared language, explicit requirements, possible solutions, and evidence about what actually works.

Agents make it possible to build software and systems extremely quickly. That changes the bottleneck. The difficult part is increasingly not how to make a thing, but what to make, why it should exist, and how to know whether it solved the real problem.

The central idea is:

When building becomes fast, the bottleneck moves up a level: define the right problem, specify what “solved” means, and use a process you can inspect and improve.

The class introduced the engineering design process as a metacognitive tool—a reusable process for improving your own thinking:

1. Define the problem.
2. Conduct background research.
3. Specify requirements.
4. Brainstorm solutions.
5. Evaluate and pick.
6. Prototype.
7. Test against the requirements.
8. Communicate the result.

Students practiced the early stages of this process in small teams, using one person as the client and the others as engineers. The compressed class exercise made it through evaluation and selection; the worksheet continues through prototyping, testing, and communication.

The most important qualification: this is a tool, not a ritual. If you already understand a problem and know a promising solution, build it. If you are spinning your wheels, the process gives you a systematic way to make forward progress.

1. The abstraction ladder

There are many valid levels at which to teach computing:

• bits, binary, and encoding;
• programming languages;
• programs and applications;
• operating systems and networks;
• large technical systems;
• the real-world problems those systems are intended to solve.

Traditional computing education often begins near the bottom of that ladder. This course begins much higher up—with agents—because an agent already contains useful knowledge about many of the layers below it. It can work with programming languages, programs, research, technical documentation, and tools on your behalf.

That leverage lets us spend more time on the upper levels: deciding what we want, describing it clearly, coordinating work, judging results, and improving the process that produced them.

The human side has an abstraction ladder too. Anatomy and biology support cognition; cognition shapes behavior; behavior interacts with goals, values, environments, and other people. These are not separate worlds. When you work with an agent, your thoughts, words, reactions, and feelings become part of the interface.

The practical lesson is to ask:

• At what level does this problem actually live?
• Is it a technical failure, a process failure, a behavioral problem, a social problem, or an unclear goal?
• Am I trying to solve a higher-level problem by changing something at the wrong level?

Choosing the right level of abstraction can simplify a problem before any solution is built.

2. Metacognition: making thinking inspectable

Metacognition means thinking about your own thinking. A metacognitive process takes reasoning that would otherwise remain implicit and puts it somewhere you can inspect:

• What problem do we believe we are solving?
• What information supports that belief?
• What would a successful outcome need to do?
• Which options did we consider?
• Why did we select this one?
• What did the test reveal about our assumptions?

Once those thoughts are written down, they can be discussed, challenged, delegated, revised, and given to an agent. A team no longer has to rely on one person’s unspoken mental model.

The engineering design process is one example of a metacognitive process. The scientific method is another. Goal clarification, planning, debugging, and retrospectives serve similar purposes: each breaks difficult thinking into stages so that weakness in one stage can be found and improved.

This is especially useful with agents. “Plan mode,” specifications, research passes, implementation plans, and test loops are not arbitrary agent features; they inherit a long tradition of engineering practice. If an agent’s result is poor, a staged process helps distinguish among causes:

• the problem was defined badly;
• relevant research was skipped;
• the requirements were incomplete;
• the solution space was too narrow;
• the prototype did not match the proposal;
• or the test did not measure the real outcome.

3. The engineering design process

The full process used in class was:

1. Define the problem

Talk to the person experiencing the problem. Ask what happens, when it happens, how often it happens, what the consequences are, what they have already tried, and why solving it matters.

The first description is rarely complete. It may contain a proposed solution disguised as a problem, several problems tangled together, or an assumption that turns out not to be true. Keep asking, “What is this actually trying to solve?”

End with a written statement—“The problem is…”—that the client recognizes as accurate. The engineers should understand it well enough to take responsibility for the next steps.

2. Conduct background research

Before inventing, learn the territory:

• How common is the problem?
• Who else experiences it?
• What solutions already exist?
• What has the client already tried?
• What does the relevant field already know?
• Why have previous attempts worked or failed?

Agents are useful here because several people can research in parallel and ask different agents to approach the same question from different directions. Bring the findings back together in a short research memo—and actually read it. Research is not decorative context; it changes the language with which the team understands the problem.

3. Specify requirements

Write a small set of criteria that a solution must satisfy. Requirements should be concrete enough to check later without prematurely locking the team into one solution.

Functional requirements describe what the solution must enable or do: its behaviors and capabilities.

Non-functional requirements describe the conditions under which the solution must operate: cost, maintenance burden, scale, reliability, security, infrastructure, training, habits, and ownership.

Requirements connect the beginning and end of the process. Testing asks whether the prototype satisfies them. If it satisfies every written requirement but still fails to solve the problem, the requirements—or even the problem definition—were incomplete.

4. Brainstorm solutions

Generate breadth before judging quality. Each person should produce several meaningfully different approaches, including:

• the cheap or lazy solution;
• a conventional solution;
• a detailed, ambitious solution;
• and at least one deliberately absurd solution.

The absurd option is useful because it stretches the design space and may reveal an assumption everyone else accepted without noticing. During brainstorming, prioritize quantity, variation, and specificity. Evaluation comes next.

5. Evaluate and pick

Compare the options against the client’s requirements. A formal version uses a requirements matrix: solutions on one axis, requirements on the other, with a score for how well each solution meets each requirement. Important requirements can be weighted more heavily.

The class used a faster version because the client was present: the client reacted to the options, identified promising pieces, and helped select a direction. Those reactions are evidence. A strong “yes” or “no” may reveal a requirement that has not yet been expressed in words.

6. Prototype

Build the cheapest version that can answer an important question. Give agents the accumulated context—the problem statement, research, requirements, and selected direction—and let them prototype different components or designs in parallel.

A prototype is not merely a smaller final product. Its job is to create evidence. It should reveal whether the proposed solution is useful, understandable, feasible, or worth pursuing.

7. Test against the requirements

Return to the written requirements and check the prototype against each one. Record failures rather than explaining them away.

Testing can send you backward:

• a failed test may require a better prototype;
• several failures may expose a bad solution choice;
• an unexpected client reaction may reveal a missing requirement;
• and a fully compliant but unhelpful prototype may expose the wrong problem definition.

That return is not failure. It is the iteration loop doing its job.

8. Communicate the result

Document what was built, why it was chosen, what evidence exists, what remains uncertain, and how another person could reproduce or continue the work.

Communication is part of engineering, not an administrative step after engineering. Large groups can only coordinate when decisions, boundaries, requirements, interfaces, and test results move reliably between people.

The complete generic process is also available on the Engineering Design Process exercise page.

4. Exercises and practices from Class 3

Exercise: client-led engineering design process

This exercise uses small teams. Each team chooses one member’s real problem; that person is the client, and the rest of the group act as engineers.

Keeping a single client gives the team a source of truth. A solution did not have to please an imaginary average user: the team could ask questions, test assumptions, and observe reactions directly. The client was encouraged to record the initial conversation so the context could later be given to an agent without relying on memory.

Problem definition as a language-building process

Teams discovered that defining a problem can take longer than expected. Useful questions narrowed the space of possible interpretations and helped locate the problem at the right level of abstraction.

The goal was not merely to collect facts. It was to develop a shared language in which the problem could be discussed. Before that language exists, a problem may be felt clearly but remain difficult to describe, divide, research, or solve.

Good problem definition asks about context, frequency, consequences, stakeholders, priorities, tradeoffs, previous attempts, and the deeper value beneath the request. Some questions will go nowhere. Asking better questions is itself a skill developed through experience.

Research as collective intelligence

Each team combined human discussion with agent-assisted research. Parallel research works best when people use different framings, compare results, and synthesize what matters rather than accepting the first generated answer.

Ten minutes of research produces roughly ten minutes of improvement. Longer engineering projects work by stacking many such increments until the team’s understanding is coherent enough to support a strong solution.

Making implicit requirements explicit

One of the richest moments in requirements work is an unexplained reaction: “That technically solves it, but I don’t want it.”

Do not dismiss that response, and do not treat it as a final explanation. Investigate it. The reaction may reveal:

• an unwanted maintenance burden;
• distrust of a tool or service;
• a hidden cost;
• a bad prior experience;
• a need for delight, control, privacy, or simplicity;
• or an assumption the engineers never asked about.

Feelings and intuition can carry real information before a person has language for it. The engineering task is to turn that signal into a requirement that can be discussed and designed around.

What the class completed

Because the session was intentionally compressed, teams practiced problem definition, background research, requirements, brainstorming, and a lightweight evaluation with their client. They did not run a full production-grade process, and the class did not pretend that a few minutes per step could produce mature requirements or tested systems.

The later worksheet stages—prototype, test, iterate, and communicate—show how the same work would continue in a longer project.

5. Problems are fractal

Big problems contain smaller problems. As the team learns more, it begins to see boundaries that let different people or agents work independently.

A software product, for example, may have a user-interface problem and a data or infrastructure problem. Those can be developed separately if the team defines an interface through which the parts connect. Each subproblem can then receive its own problem statement, requirements, prototype, and tests.

This decomposition can happen during problem definition, requirements work, prototyping, or explicit project and product management. There is no single mandatory moment. The signal is that the original problem has become too large for one coherent workstream.

This is why the process is fractal:

large problem
├── subproblem A
│   └── its own engineering design process
├── subproblem B
│   └── its own engineering design process
└── interface and integration
    └── their own requirements and tests

Large engineering achievements are possible because many groups can solve different parts, communicate through agreed boundaries, test their work, and combine the results. Iteration improves not only the product but also the team’s models, processes, and ability to coordinate.

6. Use the process when it helps

There is no universally correct process. A process is a tool that fits some situations better than others.

If you already understand a small problem and know a plausible solution, start building. The prototype itself may be the fastest way to learn. Do not turn the engineering design process into paperwork performed for its own sake.

Use more of the process when:

• you keep spinning your wheels;
• several people disagree about what the problem is;
• the first requested solution feels suspiciously narrow;
• you do not know what success would look like;
• existing attempts keep failing;
• the project is too large to hold in one person’s head;
• or an agent is producing lots of output without meaningful progress.

Use judgment about which steps need depth. A risky system may require extensive research, security requirements, and formal testing. A personal weekend tool may only need a conversation, a quick prototype, and direct feedback.

There is also a deeper limit: not everything valuable in life is problem-shaped. Connection, meaning, taste, rest, and exploration do not always improve when forced into an engineering frame. The process is powerful precisely because it is a tool—not a total theory of how to live.

7. Choose the right tool for the problem

Once you have a powerful agent, it is easy to reinterpret every difficulty as an AI problem. This is a form of solutionism: beginning with the tool you want to use and bending the problem until it seems to require that tool.

Pause before building:

• Does this problem require AI?
• Does it require software at all?
• Is the problem located at the level I am trying to change?
• Would a conversation, decision, habit, existing product, or offline action work better?

If agent work creates a narrowing, over-focused feeling, step away for a moment. Take a walk, return to the abstraction ladder, and check whether you are solving the right problem at the right level.

8. Homework

The week’s homework has two connected parts.

Set one weekly goal

Run the Weekly Goal-Setting prompt in Zo. Choose the single outcome that would create the most progress this week. Make it concrete, achievable within the week, and easy to demonstrate in roughly three minutes at the next class.

The agent should help sharpen the outcome, reduce its scope if necessary, break it into tasks, and record it in the Fractal Accelerator project folder. That one goal becomes the driving vector for the week’s work, report, and demo.

Learn one skill from the reference library

Choose one guide or topic from the Fractal Accelerator reference library that matters to your current work. Give the page to your agent and ask it to help you create a personal study guide or work through the material.

This is deliberately self-directed. The library contains more than class time can cover, and the skill of using agents to teach yourself is part of the course. If the agent teaches in a way that does not work for you, that itself becomes an engineering problem: clarify the goal, state the requirements of a useful lesson, and iterate.

Keep building toward the weekly goal, bring specific blockers to office hours, and be ready to demo what changed.

Compact glossary