The two modes
From vibe coding toward agentic engineering.
This is the idea the docs hang on. Vibe coding gets people building quickly. Agentic engineering is the disciplined practice of directing agents while keeping human responsibility for the spec, quality, security, and design.
Groundwork is the trailhead and first stretch, not the summit. It will not make you an agentic engineer by itself; that takes years of judgment, design practice, review, security awareness, and taste. What it does is show the arc, set up the environment, and give you the first serious practice aimed in the right direction.
Raises the floor
Access. Momentum. Prototypes. You prompt, run, accept, and iterate until something appears. It is a wonderful way to learn and a risky way to stop learning.
Raises the ceiling
Throughput at professional quality. You still use agents, but you own the plan, the tests, the review, the security boundaries, and the architecture.
#The floor: vibe coding
Vibe coding means giving the agent a goal in plain language, letting it write the code, running the result, and feeding errors back until the thing works. It is useful, joyful, and a real doorway into software for people who would otherwise never start.
The catch is that a working demo is not the same as understanding. When the code breaks, leaks data, grows brittle, or has to be maintained by a team, you need more than momentum.
#The ceiling: agentic engineering
Agentic engineering keeps the speed but adds responsibility. You orchestrate agents, but you do not outsource the parts that require judgment: what should be built, what must never break, how the system should be shaped, and how you know the result is safe and correct.
That is why Groundwork teaches boring-looking fundamentals beside modern AI tools. The shell, Git, tests, project instructions, and review habits are how you direct the agent instead of being dragged by it.
#The five chops
These are the durable skills that stay yours even as agents write more of the code.
Write the goal, invariants, edge cases, security boundaries, and acceptance criteria before the agent starts. The prompt is not just a request; it is a design artifact.
Practice: write acceptance criteria for a change before allowing an agent to edit.
Read generated code for whether it is right, maintainable, and scoped, not just whether tests pass. Plausible-but-wrong code is the core failure mode.
Practice: read every agent diff and name one risk before accepting it.
Turn quality into signals: tests, checks, evals, scripts, screenshots, logs, or manual verification steps. If you can verify it, agents can move faster inside the rails.
Practice: convert each acceptance criterion into a check or test.
You are still responsible for secrets, auth, permissions, injections, data exposure, dependency risk, and accidental public leaks. Speed is not an excuse.
Practice: ask what the change could leak, let in, or silently corrupt.
Know the difference between code that works and a system that will hold. Taste comes from seeing patterns, studying failures, and making tradeoffs explicit.
Practice: once a week, study one design pattern or postmortem and compare it to an agent's default solution.
#Why you still put in the hours
If an agent can write code, why practice keyboard shortcuts, Git, architecture, and tests? Because fluency is what lets you supervise. You cannot reliably review a diff you cannot read, recover from a bad change without Git, or direct a system you do not understand.
Start on the floor. Ship something. Then climb: spec, review, evals, security, and taste. That climb is the difference between being impressed by an agent and being able to lead one.
#Go deeper
Karpathy's one-year retrospective on agentic engineering Sequoia AI Ascent 2026 talk search Groundwork Practice plan