# Module 14: Agentic Development ## Lesson 4: Choosing Your Code Format **Understanding what the agent produces and which technology fits your needs** --- ## The Agent Writes Code. Which Kind? When you ask an agent to build something, one of the first decisions is: what technology should it use? This choice affects how fast you can iterate, how easy it is to share, and how close the output is to production. You don't need to become an expert. But you need to understand the options well enough to make good decisions — or at least ask the right questions. --- ## The Most Common Stack: React + Tailwind Most modern web projects use some version of this combination. If you're building production code, this is likely what you'll work with. **React** handles structure and behavior — you build reusable components that manage their own state. **Tailwind CSS** handles styling — instead of writing CSS in separate files, you apply utility classes directly to elements. **Next.js** ties it all together — routing between pages, server features, and deployment. ```jsx function SignupForm() { const [email, setEmail] = useState('') const [error, setError] = useState('') function handleSubmit() { if (!email.includes('@')) { setError('Please enter a valid email') } } return (

Create Account

setEmail(e.target.value)} className="w-full border rounded p-3 mb-4" placeholder="Email" /> {error && {error}}
) } ``` Notice how everything — structure, styling, and behavior — lives in one component file. This is what modern web development looks like. | | | |---|---| | **Pros** | Industry standard. Components are reusable. Real interactivity. Deploys easily to Vercel. The agent is very good at generating this stack. | | **Cons** | Requires a development environment (Node.js, package manager). Can't just open a file in the browser. Errors can be cryptic. Steeper learning curve. | | **Best for** | Production projects. Interactive prototypes. Building within an existing codebase. | --- ## Component Libraries and Your Design System In Module 13, you built a design system — tokens for colors, typography, spacing, and component definitions. In code, these come to life through **component libraries**. A component library is a collection of pre-built, styled components (buttons, inputs, cards, modals) that you use as building blocks. Instead of writing a button from scratch every time, you import one: ```jsx import { Button } from '@/components/ui/button' import { Input } from '@/components/ui/input' function SignupForm() { return (
) } ``` ### Popular component libraries | Library | What it is | |---|---| | **shadcn/ui** | Copy-paste components built on Tailwind. You own the code. Highly customizable. Currently the most popular choice. | | **Radix UI** | Accessible, unstyled primitives. You add your own styling. The foundation under shadcn/ui. | | **Material UI (MUI)** | Google's design system as React components. Opinionated look and feel. | | **Chakra UI** | Utility-based components with built-in accessibility. | ### How this connects to your design system Your design tokens (Module 13) define the rules. The component library implements them: | Design token | Code implementation | |---|---| | Primary color: `#0066FF` | `--primary: #0066FF` in your Tailwind config | | Font: Inter, 16px base | `fontFamily: { sans: ['Inter'] }` in config | | Spacing: 8px scale | `spacing: { 1: '8px', 2: '16px', ... }` | | Button: primary variant | ` ``` One file. Double-click to open. Instant prototype. | | | |---|---| | **Pros** | Zero setup. One file. Consistent styling with utility classes. Easy to share. Fast iteration. | | **Cons** | No real interactivity without adding JavaScript. Not production code. Tailwind CDN is for prototyping only. | | **Best for** | Rapid exploration. Client reviews. Testing layouts and visual direction before committing to a framework. | --- ## The Simplest Option: HTML + CSS + JavaScript The foundation of the web. Every browser understands these three languages natively. No framework, no library, no build step. - **HTML** — the structure (what elements exist and how they're organized) - **CSS** — the visual styling (colors, fonts, spacing, layout) - **JavaScript** — the behavior (what happens when you click, type, or scroll) These can be combined in a single `.html` file for quick explorations, or split into separate files for organized work: ```html

Create Account

``` ```css /* appearance */ .signup-form { max-width: 400px; padding: 32px; font-family: Inter, sans-serif; } .signup-form button { background: #0066FF; color: white; padding: 12px 24px; } .error { color: #DC2626; font-size: 14px; display: none; } ``` ```javascript // behavior document.getElementById('submit-btn').addEventListener('click', function() { const email = document.getElementById('email').value const error = document.getElementById('email-error') if (!email.includes('@')) { error.textContent = 'Please enter a valid email' error.style.display = 'block' } }) ``` | | | |---|---| | **Pros** | No setup. No dependencies. Universal. You can read the structure, styles, and behavior separately. Opens in any browser. | | **Cons** | Everything is manual. No components or reusability. Gets messy in larger projects. More code to wire things together. | | **Best for** | Learning the basics. Quick one-off prototypes. When you want full control with no abstractions. | --- ## Other Frameworks | Technology | When you'll see it | |---|---| | **Svelte / SvelteKit** | Simpler alternative to React. Less boilerplate. Growing in popularity. | | **Vue / Nuxt** | Another React alternative. Popular in some teams and regions. | | **TypeScript** | JavaScript with type safety. Production projects often require it. The agent handles it well. | You don't choose these — your project does. If you're joining an existing codebase, you use what's already there. If you're starting fresh, the agent can help you pick. --- ## Static vs. Executable: Where They Live ### Static prototypes Placed in the scenario folder alongside their specifications. This keeps the visual output next to the spec it was built from: ``` docs/C-Scenarios/S01-User-Registration/ ├── scenario-overview.md ├── P01-landing-page/ │ ├── specification.md │ └── prototype.html ← Static prototype ├── P02-signup-form/ │ ├── specification.md │ └── prototype.html ← Static prototype └── shared/ ├── styles.css ← Shared styles across pages └── interactions.js ← Shared behavior ``` ### Executable code Organized in the root of the repository, following the project's framework structure: ``` my-project/ ├── src/ │ ├── components/ │ │ ├── SignupForm.tsx │ │ └── ui/ ← Component library │ ├── pages/ │ │ ├── index.tsx │ │ └── signup.tsx │ └── styles/ │ └── globals.css ├── docs/ ← Specs still live here ├── package.json └── ... ``` --- ## Choosing the Right Format | Situation | Format | Why | |-----------|--------|-----| | Exploring a layout idea | HTML + Tailwind | Fast, disposable, zero setup | | Reviewing with a client | Static HTML | Easy to share, no setup for viewer | | Rapid component iteration | HTML + Tailwind | Consistent styling, quick changes | | Building a production feature | React + Tailwind | Ships directly into the codebase | | Testing real form validation | React | Needs real state management | | Designing a new page | Static first | Iterate fast, then migrate | | Adding to an existing app | Match the existing stack | Must fit the codebase | Many projects use both categories: static HTML for exploration, framework code for implementation. Start light, go heavy when you need to. --- ## Practical Tips ### For static prototypes - Ask the agent: "Build this as a single HTML file I can open in my browser" - Use Tailwind CDN for fast styling without setup - Share by sending the file — email, Slack, cloud drive - Place prototypes in the scenario folder next to the specification ### For executable code - Ask the agent: "Build this as a component in our [framework] project using our design system" - Make sure your development environment is running before you start - Deploy to a preview URL (Vercel, Netlify) when you need to share - Keep the Agent Dialog updated with the branch and commit information ### When to ask a developer - You're not sure which technology the project uses - The development server won't start - You get build errors you don't understand - You need to set up a new project from scratch --- ## What's Next Whether you're producing static HTML or executable code, you need a way to keep your work safe, organized, and shareable. That's where Git comes in. --- **[Continue to Lesson 5: Git Discipline →](lesson-05-git-discipline.md)** --- [← Back to Lesson 3](lesson-03-when-you-get-stuck.md) | [Back to Module Overview](module-14-agentic-development-overview.md) *Part of Module 14: Agentic Development*