#Auto code 100% ?

1 messages · Page 1 of 1 (latest)

fallow pebble
#

OpenClaw:

From what I’ve read, OpenClaw was mostly developed using AI tools

So, if I understand correctly, the founder initially coded it using Claude CLI, manually clicked “accept” on each Claude request, and then gradually built OpenClaw itself, eventually using OpenClaw to continue developing OpenClaw

Is that the actual story?

If so, does that mean that if we give OpenClaw a complete specification document from A to Z, and it breaks it down into tasks, then assign multiple agents to those tasks, each with a specific specialty, plus sub-agents with even more precise specialties, we could theoretically develop an entire project from start to finish?

Is that really possible today? Has anyone already done this successfully?

I was thinking about building an agent that reads a full specification document, breaks it down into Agent/Human tasks in Monday, and then, once that is done, having Monday trigger events whenever a task is completed

Those events would then launch the right development agents, each agent would work on the code, commit its changes to GitHub, and another agent would review and validate the commits

Finally, a human would review the overall result

What do you think about this approach?

Do you already have an efficient process for this kind of workflow?

proper egretBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

normal rootBOT
# fallow pebble OpenClaw: From what I’ve read, OpenClaw was mostly developed using AI tools So...

Short version: yes, that is broadly the shape of the story, but I’d avoid treating it as “write perfect spec, press button, get finished product.”

AI-assisted development works today, and OpenClaw is very much built around that direction: humans steer, agents do focused chunks of work, other agents can review/test, and the system keeps more context around the workflow. But the reliable pattern is not one giant autonomous waterfall. It is smaller loops:

  1. human defines goal + constraints
  2. agent proposes a plan and splits work
  3. humans approve risky/product decisions
  4. agents implement bounded tasks in branches/worktrees
  5. tests/lint/build run automatically
  6. review agent checks diffs
  7. human reviews final behavior and merges

Your Monday idea is reasonable as an orchestration layer: spec → task decomposition → human/agent ownership → event-triggered agents → review/validation → human approval. I’d keep the first version conservative though. Let Monday trigger agents for clearly bounded tasks, but do not let them directly push/merge to main without gates.

The hard parts are usually not “can an agent write code?” They are:

  • specs are incomplete or ambiguous
  • agents need repo-specific context and conventions