Webbo3 Data Analysis Bootcamp · Web Development Module · Lesson 1

Using GitHub Copilot to Scaffold HTML Pages: Accepting, Rejecting, Editing Suggestions, and Prompting with Comments

A practical lesson on how to use GitHub Copilot as a coding assistant for HTML, when to trust its suggestions, when to reject them, and how to prompt it effectively using comments.

Writing HTML by hand is not difficult, but it is repetitive. Every page needs the same boilerplate: DOCTYPE, html, head, body, meta tags, link tags, script tags. Every form needs labels, inputs, and validation attributes. Every navigation bar needs a list of links, often with dropdown menus and responsive breakpoints. GitHub Copilot, an AI-powered code completion tool built into modern editors like Visual Studio Code, can generate this scaffolding in seconds. But Copilot is not a mind reader. It predicts what you want based on context, comments, and patterns from millions of public code repositories. Sometimes it is exactly right. Sometimes it is close but needs editing. Sometimes it is confidently wrong, generating code that looks plausible but contains subtle errors, outdated practices, or security vulnerabilities. This lesson teaches you to use Copilot as an accelerant, not a replacement for your own judgment. You will learn how to scaffold HTML pages efficiently, how to accept and reject suggestions wisely, how to prompt Copilot with comments for better results, and most importantly, when to turn it off and write the code yourself.

1. What Is GitHub Copilot and How Does It Work?

GitHub Copilot is an AI pair programmer powered by OpenAI Codex, a large language model trained on billions of lines of public code from GitHub repositories. It runs as an extension inside your code editor, most commonly Visual Studio Code, but also JetBrains IDEs, Neovim, and GitHub Codespaces. As you type, Copilot analyzes the context of your current file, nearby files, open tabs, and the comments you have written. It then predicts the most likely next lines of code and presents them as gray ghost text that you can accept, reject, or partially edit.

How the suggestions appear. In Visual Studio Code, Copilot suggestions show as faded gray text after your cursor. Press Tab to accept the entire suggestion. Press Ctrl + Right Arrow to accept one word at a time. Press Esc to reject it entirely. If multiple suggestions are available, press Ctrl + Enter to open the Copilot panel and see up to ten alternatives. This is useful when the first suggestion is not quite right but one of the alternatives is.

Copilot does not understand your intent. This is the most important concept in this lesson. Copilot does not know what you are trying to build. It does not know your business requirements, your design system, your accessibility standards, or your company's coding conventions. It predicts based on statistical patterns. If millions of repositories include a certain pattern, Copilot will suggest it even if that pattern is outdated, insecure, or inappropriate for your specific project. For example, Copilot might suggest using a table element for page layout because it saw that pattern in old code, even though modern HTML uses CSS Grid or Flexbox for layout. It might suggest inline event handlers like because it saw them in beginner tutorials, even though modern best practice uses addEventListener in a separate JavaScript file. You must evaluate every suggestion before accepting it.

Copilot learns from your context. The quality of suggestions improves dramatically when you provide context. If you open a blank HTML file and type nothing, Copilot has no idea what you want. If you type a comment describing your goal, or if you already have a CSS file open with your design system defined, Copilot can generate HTML that matches your existing styles. The more context you give, the better the predictions. This is why prompting with comments is one of the most effective techniques, and it is covered in detail later in this lesson.

2. Scaffolding HTML Pages with Copilot

Scaffolding means generating the basic structure of a file so you can fill in the specifics. Copilot excels at this because boilerplate HTML is highly predictable. The DOCTYPE declaration, the html element with lang attribute, the head section with meta charset and viewport, the title, and the body are nearly identical across every modern HTML page. Copilot can generate this in one keystroke if you give it the right starting prompt.

Generating the HTML5 boilerplate. Open a new file named index.html in Visual Studio Code. Type the exclamation mark and press Tab, or simply start typing DOCTYPE. Copilot will almost certainly suggest the complete HTML5 boilerplate:

  
  
  

Press Tab to accept. In under a second, you have the skeleton of a standards-compliant HTML5 page. Compare this to typing it manually, which takes thirty seconds even for an experienced developer. This is where Copilot provides genuine value: eliminating repetitive typing so you can focus on the unique parts of your page.

Scaffolding a complete page structure. Once the boilerplate is in place, you can scaffold larger sections. Place your cursor inside the body element and type a comment describing what you need:

Press Enter and wait for Copilot to suggest the HTML. It will likely generate something like:

This is a solid starting point. It uses semantic HTML with the nav element, includes a logo, an unordered list of links, and a button. However, you must evaluate it before accepting. Does the class name navbar match your CSS framework? If you are using Bootstrap, the class should be navbar navbar-expand-lg. Does the href attribute use hash links that you do not need? Should the button be an anchor tag instead? Are the link text values appropriate for your actual site? Copilot gives you structure. You must give it accuracy.

Scaffolding forms. Forms are another area where Copilot shines because form elements are highly patterned. Type a comment:

Copilot will likely suggest:

This is excellent scaffolding. It includes proper label associations with for and id attributes, correct input types, required attributes for validation, and a semantic button. But you must still check: does the action attribute point to a real endpoint? Is the method POST appropriate, or should it be GET for a search form? Do you need additional attributes like pattern for phone numbers, or minlength and maxlength for text fields? Copilot generates the common case. Your job is to customize it for your specific requirements.

Scaffolding responsive layouts. Copilot can also suggest CSS Grid or Flexbox layouts when prompted with comments. Type:

Copilot might suggest:

This uses semantic HTML with aside and main elements, which is correct for accessibility. But again, evaluate the class names. Are they compatible with your CSS? Does the structure match your design mockup? Copilot accelerates the typing, but it does not replace your design decisions.

3. Accepting, Rejecting, and Editing Suggestions

The most important skill in using Copilot is not accepting suggestions quickly. It is knowing when to accept, when to reject, and when to accept partially and edit. This judgment comes from understanding HTML, not from trusting the AI.

When to accept a suggestion immediately. Accept when the suggestion is pure boilerplate that you would have typed identically yourself. The HTML5 DOCTYPE and basic structure, standard meta tags, common form elements with proper attributes, and semantic HTML patterns like nav, header, main, and footer are all safe to accept. These are well-established standards with little room for variation. If Copilot suggests a nav element with an unordered list of links and you need exactly that, press Tab and move on.

When to reject a suggestion entirely. Reject when the suggestion contains outdated practices, incorrect semantics, or security risks. Common red flags include: table elements used for page layout instead of CSS Grid or Flexbox; inline styles like style="color: red;" instead of class-based CSS; inline event handlers like onclick or onsubmit instead of external JavaScript; missing alt attributes on img tags; form inputs without associated label elements; deprecated tags like center, font, or marquee; and hardcoded placeholder text like "Lorem ipsum" or "Your content goes here" that you might forget to replace. If you see any of these, press Esc and write the code yourself or type a more specific comment to guide Copilot toward better output.

When to accept partially and edit. This is the most common scenario. Copilot suggests something that is 80 percent correct but needs customization. For example, it might generate a form with input type="text" for a phone number field, when you actually need input type="tel" with a pattern attribute for validation. Or it might suggest a navbar with generic link text like "Home" and "About" when your actual navigation needs "Dashboard," "Reports," and "Settings." In these cases, accept the suggestion with Tab, then immediately edit the specific parts that need changing. Do not leave the generic text in place. Every placeholder is a bug waiting to be discovered by a user.

Using Ctrl + Right Arrow for word-by-word acceptance. Sometimes the first half of a suggestion is perfect and the second half is wrong. Instead of accepting the whole thing and then deleting the bad part, press Ctrl + Right Arrow to accept one word at a time. Stop when the suggestion deviates from what you want, then continue typing your own code. This gives you fine-grained control and prevents the frustration of accepting a large block of incorrect code.

Opening the Copilot panel for alternatives. When the first suggestion is not right but seems close, press Ctrl + Enter to open the Copilot panel. This shows up to ten alternative completions ranked by probability. One of them might be exactly what you need. For example, if you are scaffolding a data table and the first suggestion uses div elements with class names, an alternative might use the proper table, thead, tbody, tr, and td elements, which is more appropriate for tabular data. Browse the alternatives before rejecting entirely.

Editing suggestions for accessibility. Copilot often generates HTML that is structurally correct but accessibility-deficient. For example, it might suggest an img tag without an alt attribute, or a button without a type attribute, or a form input without an associated label. These are not syntax errors. The code will render in a browser. But it will fail screen readers, keyboard navigation, and accessibility audits. After accepting any suggestion, run through this mental checklist: does every img have an alt? Does every input have a label with a matching for attribute? Does every button have a type? Are heading levels sequential, h1 followed by h2, not h1 followed by h4? Copilot does not prioritize accessibility unless your comments explicitly request it. You must.

4. Prompting Copilot with Comments

Comments are the primary way to communicate intent to Copilot. The model reads your comments as instructions and generates code that attempts to fulfill them. The quality of your comments directly determines the quality of the suggestions. Vague comments produce vague code. Specific, detailed comments produce specific, useful code.

Be specific about structure and semantics. A comment like "navbar" might produce a div with class="navbar" and anchor tags. A comment like "semantic navbar with nav element, logo as h1, ul for links, and a button with aria-label" produces something far more precise and accessible:

Notice the improvement. The nav element has an aria-label for screen readers. The logo is an h1, which is correct for the page hierarchy. The button has a type and an aria-label. These are not accidents. They are the direct result of a detailed comment that told Copilot what standards to follow.

Include framework or library names. If you are using a specific CSS framework or JavaScript library, mention it in the comment. Copilot will generate code that follows that framework's conventions:

This produces:

  
  

    

Card title

    

Some quick example text.

    Go somewhere
  

The class names match Bootstrap's documentation exactly. Without the comment mentioning Bootstrap, Copilot might invent its own class names that do not match any framework. The same principle applies to Tailwind CSS, Material UI, or any other system. Name the system in your comment, and Copilot will align with it.

Chain comments for complex structures. For a complete page, write a series of comments that describe each section in order. Copilot will generate code that follows your sequence:

After each comment, press Enter and let Copilot generate the section. The resulting HTML will have a logical document flow that matches your outline. This is faster than writing each section from scratch and ensures you do not forget structural elements like a footer or a main wrapper.

Use comments to enforce standards. If your team requires specific practices, mention them in comments. For example: "Form with CSRF token input," "Image with lazy loading and WebP format," "Table with scope attributes on th elements for accessibility." Copilot will incorporate these requirements into its suggestions because it recognizes the patterns from repositories that follow similar standards. This turns Copilot into a compliance tool, not just a typing accelerator.

5. When NOT to Use AI Autocomplete Practically

Copilot is a powerful tool, but it is not appropriate for every situation. There are specific contexts where using it will slow you down, introduce errors, or create technical debt that costs more time to fix than it saved. Knowing when to turn it off is as important as knowing when to use it.

When learning a new concept for the first time. If you are new to HTML and still learning how the DOM works, what semantic elements mean, or why accessibility attributes matter, do not use Copilot. Autocomplete will generate correct-looking code that you do not understand, and you will not learn from it. You will develop a habit of pressing Tab without reading, which produces functional illiteracy. You can write HTML that renders in a browser without knowing what you wrote. That is not competence. It is dependency. Turn Copilot off in your editor settings when you are doing tutorial exercises, following along with this bootcamp, or completing homework assignments. Type every tag, every attribute, and every value by hand. The muscle memory and the conceptual understanding you build are worth far more than the seconds you save with autocomplete.

When writing security-sensitive code. Copilot is trained on public repositories, which include code with security vulnerabilities, hardcoded secrets, SQL injection flaws, and cross-site scripting holes. It can confidently suggest an input field without sanitization, a form that submits to an HTTP endpoint instead of HTTPS, or an authentication pattern that stores passwords in localStorage. These suggestions look correct because they are syntactically valid, but they are dangerous. For any code that handles user authentication, payment information, personal data, or API keys, write it manually. Review every line against the OWASP Top Ten and your organization's security policies. Do not let Copilot anywhere near production security code.

When working with proprietary or regulated data. Copilot sends your code context to GitHub's servers for prediction. If you are working on a project with proprietary business logic, patient health data under HIPAA, financial records under PCI-DSS, or any data subject to non-disclosure agreements, using Copilot may violate compliance requirements. GitHub has introduced Copilot Business and Copilot Enterprise with enterprise-grade privacy commitments, but the free and individual plans do not guarantee that your code will not be used to train future models. If you are unsure about your organization's policy, ask your manager or compliance officer before using Copilot on work projects. For personal learning and open-source projects, this is not a concern.

When the code must follow strict organizational standards. Every company has coding standards: specific class naming conventions, mandatory linting rules, required accessibility checks, and approved library versions. Copilot does not know your company's standards unless they are explicitly mentioned in your comments or visible in your open files. It might suggest a class name that violates your naming convention, or a third-party library that is not approved by your security team, or an HTML structure that fails your automated accessibility tests. In these environments, Copilot creates more cleanup work than it saves. Use it only for personal scaffolding, then rewrite the code to match your team's standards before committing.

When debugging complex logic. Copilot predicts what comes next based on patterns. It does not debug. If your HTML is rendering incorrectly because of a subtle CSS specificity conflict, a missing closing tag three hundred lines up, or a JavaScript event listener that fires in the wrong order, Copilot will not diagnose the problem. It will suggest more code that compounds the confusion. Debugging requires systematic thinking: isolating the problem, testing hypotheses, reading documentation, and inspecting the DOM in browser developer tools. These are human skills that AI cannot replicate. Turn Copilot off when you are deep in debugging mode. The suggestions are distractions, not solutions.

When writing comments and documentation. Copilot can suggest comments, but they are often generic, inaccurate, or describe what the code does rather than why it does it. Good documentation explains intent, business context, and edge cases. Copilot cannot know your business context. It will suggest "This function handles the form submission" when what you actually need is "This form submits to the payment gateway API. It must include the CSRF token and validate the card number format before sending. See PCI-DSS requirement 6.5.1." Write your own comments. They are the most important part of your code for future maintainers, including yourself in six months.

Using AI to Move Faster in HTML Development

Copilot is one AI tool among many. Used correctly, it accelerates the mechanical parts of HTML development so you can focus on architecture, accessibility, and user experience. Used incorrectly, it creates a dependency that weakens your skills and introduces subtle bugs. Here is how to integrate Copilot into a broader AI-assisted workflow.

1. Use Copilot for structure, then audit with AI accessibility tools.
After scaffolding a page with Copilot, paste the HTML into an AI accessibility checker like WAVE, axe DevTools, or an online validator. Ask a general AI assistant: "Review this HTML for accessibility issues. Check for missing alt attributes, unassociated labels, incorrect heading hierarchy, and missing ARIA landmarks." This two-step workflow, generate with Copilot, audit with AI, correct manually, produces better code than either tool alone.

2. Generate component variations with Copilot, then select the best.
If you need three different hero section layouts for a client presentation, use Copilot to scaffold each one with different comments: "Hero with left-aligned text and background image," "Hero with centered text and gradient background," "Hero with two-column layout and embedded video." Accept each suggestion into a separate file or branch. Then review them with your design team or client and pick the best. Copilot acts as a rapid prototype generator, not a final decision-maker.

3. Use AI to explain Copilot suggestions you do not understand.
If Copilot suggests an HTML pattern you have never seen, for example a details and summary element for an accordion, do not accept it blindly. Ask a general AI assistant: "What does the details and summary element do in HTML5? When should I use it instead of a div with JavaScript?" Use the explanation to decide whether the suggestion fits your project. This turns every unfamiliar Copilot suggestion into a learning opportunity rather than a black box.

4. Document your own patterns for Copilot to learn from.
Copilot learns from the files you have open. If you maintain a style guide HTML file with your team's standard navbar, footer, form, and card components, keep it open in a tab while working on new pages. Copilot will reference its class names, structure, and conventions when generating new suggestions. This is how you turn Copilot from a generic tool into a team-specific assistant. The open file acts as a prompt that does not need to be retyped.

5. Turn Copilot off during deliberate practice.
The most important AI-assisted workflow tip is knowing when to remove AI from the workflow entirely. When you are doing the HTML exercises in this bootcamp, disable Copilot in your VS Code settings. Go to Settings, search for Copilot, and uncheck the enable boxes. Type every tag by hand. Make mistakes. Fix them. Read the MDN documentation for every element you use. This is slow, but it is how you build the judgment that lets you use Copilot effectively later. A developer who cannot write HTML without Copilot is not a developer who uses AI. They are a developer who is used by AI.

A habit worth building from this lesson onward: start every HTML project by writing a comment outline of the page structure, then use Copilot to scaffold each section, then audit every generated block for accessibility, semantics, and alignment with your design system. Accept what is correct, edit what is close, reject what is wrong, and never let the tool write code you cannot explain to another human being.

Next lesson: CSS fundamentals, selectors, the box model, and responsive design with Flexbox and Grid.