A designer’s sketchbook is a beautiful mess: half-formed ideas, crossed-out attempts, margins full of notes. Nobody expects it to be a finished product. The sketchbook exists to find out whether an idea has legs before you invest the time and effort to make it real.
At some point, though, the sketch has to become a design - something structured enough that others can work from it, reproduce it, and build on it. Both are creative but the approaches are different.
AI-assisted coding has exactly the same split. Understanding what stage you’re at is one of the most important judgements you can make.
The sketchbook: vibe coding as a validation tool
“Vibe coding” - using AI to build something fast with little or no traditional engineering involved - has earned itself a bad rap. But used correctly, it’s one of the most powerful tools available to founders and product teams.
This is the sketch where the goal isn’t a finished product, it’s to find out whether the idea has legs. You put something in front of users, see how they respond, and iterate. The roughness isn’t a bug, it’s a feature.
At this stage, the discipline isn’t in how you build, the discipline is in knowing it’s a sketch. This code should never go to production. The temptation - especially when something is working and users are responding - is to keep building on top of it. But, at some point, you have to put down the sketchbook and start designing.
The finished design: AI-assisted engineering
When a skilled engineer directs a coding agent, this is not vibe coding. This is producing work that others will use, build on, and maintain for the future. This is still creativity but the standards are different.
A finished design isn’t less creative than a sketch but it’s more considered and the choices are deliberate. The structure serves everyone who comes after you - the next engineer, or the next team.
The structure here acts as guardrails and they are more important in AI coding than ever. In the same way a human team defines norms for how they write code, you need to define them for your agent. For the agent, they need to be precise and they must be automated: automated testing, test coverage thresholds, linting, security scanning. These can’t be optional, they must run before every commit.
Watch for the workarounds
In my experience, coding agents will find ways around constraints if you let them. You’ll see it as an ‘ignore’ comment on a linting rule, a file quietly added to .gitignore, or a test that passes coverage requirements without actually testing anything meaningful.
Left unchecked, this will erode the system so you have to watch for it and instruct the agent explicitly not to do it. And when it gets stuck - which it will, especially in test files where you sometimes have to approach things differently than you would in production - help it find the right path rather than the easy one.
Which goes to show that human review isn’t optional. The automated tools catch a lot but they won’t catch everything. Someone still needs to look at what’s been produced and make a judgement about whether it’s right.
The creative director, not the draftsperson
A creative director doesn’t draw every line but they decide what to create, direct the people doing the work, and evaluate whether the output meets the standard. That’s the same skill set you need to work effectively with a coding agent.
You need to decide what to delegate, write clear instructions, and evaluate the output. You need to check not just that it works, but whether it’s been done in a sustainable way.
Frameworks like OpenSpec or Spec Kit - tools that help you define what you’re building before you start building it - can help with the definition side. Linters and automated tests handle much of the output evaluation. But the judgement - what to build, how to approach it, when something isn’t right - that’s still yours. Use the automated tools to build your guardrails, your value is in the decisions that shape what gets built.
A team of digital teammates
Instead of a team of human engineers, you now have a team of digital ones. They’re fast, tireless, and remarkably capable, but the quality of what they produce depends entirely on the quality of the direction they receive - and on knowing from the start whether you’re sketching or designing.