How I Actually Use AI With Python: A Web Dev's Honest Wor...

A question in a Telegram group made me stop and think — and then write this.

Someone in a Python Telegram group I'm part of dropped a question that stuck with me:

"How do you use AI with Python? Does anyone have an interesting workflow? Prompt engineering? Loop engineering? Prompt templates?"

It's a great question — and a surprisingly hard one to answer, because AI is still so new that most of us are figuring it out in real time. Unlike other technological shifts where humanity had centuries to adapt, AI is moving so fast we barely have a decade to even understand what's happening, let alone decide if it's good or bad. But that's a conversation for another post.

The real question here is practical: how do you actually integrate AI into your day-to-day Python work?

I want to share my humble method. I work mostly in web development — Django, templates, frontend components — so everything I describe is centered around that. For other domains, the same principles probably apply, but the specifics will differ. Also worth noting: I only use free, non-local AI services. No paid APIs, no local models.

The Foundation: Always Start With Context

Before any scenario, before any task, I always feed the model the file tree of the project and a short description of what it does. This is non-negotiable. The model needs to know what world it's operating in.

This applies to every session, every task. And it leads directly to the most important lesson I've learned:

Document everything. Save your session URLs. Never repeat the context stage if you don't have to.

I keep the full URL of every AI conversation I use for a project. That way, when I come back the next day — or next week — I can continue where I left off. The model already knows the project. I just pick up the thread.

Scenario 1: Restyling Old or New Django Templates

This is the task I use AI for most. My workflow has three stages.

Stage 1: Study

I feed the model a full collection of approved templates — the ones that come with the admin dashboard or any file that contains clear examples of tables, headers, menus, colors, widgets, and typography.

If the project uses something like AdminLTE, I give the model the technical specs: Bootstrap version, color palette, component structure. If I can, I paste the actual template files.

The goal of this stage isn't just to give information — it's to verify that the model actually understands the project. I do this through questions. I ask the model to describe the UI, the color scheme, the layout patterns. If its answers match reality, we move on.

Stage 2: Production

Once I'm confident the model understands the visual language of the project, I ask it to write a style guide:

"Act as an expert UI/UX designer and write a detailed style guide for this application."

This step forces the model to consolidate everything it learned into a single reference. It's also a final check — if the style guide looks right, the model is ready to work.

Then I ask it to generate a reusable prompt for restyling Django templates:

"Based on what we know about the project, write a prompt for restyling Django templates that: updates styles only and doesn't touch anything else. I want to use it like this: <prompt> <template code>"

From here on, restyling a template is a one-liner. Paste the prompt, paste the template, get the result.

Stage 3: Refinement

The first version of the prompt is rarely perfect. I've run into cases where the model:

Removed descriptive titles and subtitles from templates
Wrapped content in Bootstrap card containers instead of using full available width

Each time something goes wrong, I add a specific clause to the prompt. Over time, the prompt becomes more precise and the results get closer to what I actually want.

Scenario 2: Building Web Components

Once Scenario 1 is done, Scenario 2 becomes almost trivial — because I already have a working style prompt. Now I just need to adapt it for building native Web Components instead of restyling existing templates.

I ask the model to rewrite the previous prompt for this new purpose:

"I have this prompt. I want you to rewrite it for building Web Components. I want to use it like this: <prompt> {{json}}. The final component should be used like this: <my-component backend-url="{{ url 'endpoint' }}"></my-component>"

The same refinement process applies here. I add clauses for naming consistency, style consistency, and any edge cases that come up in practice.

The Prompts I Actually Use

Here are the two production prompts I've developed through this process.

Prompt: Generate Web Components

Act as an expert Frontend developer specializing in Web Components and clean architecture.
I will provide a JSON structure from a backend endpoint. Your goal is to generate a set of
native Web Components packaged in a single JavaScript file, along with a Django/Bootstrap template.

Follow these rules strictly:

1. ARCHITECTURE:
   - Deliver a single complete file ready to save at static/js/wc_[module]_components.js.
   - Use a single global DashboardStateManager instance to centralize the fetch(url) call
     and avoid duplicate requests. Components must subscribe to this state in connectedCallback.

2. STYLES & RESPONSIVENESS (GENTELELLA STYLE):
   - Use clean fonts and inject a shared style block at the start of each Shadow DOM.
   - Color palette: card backgrounds #ffffff, borders #E6F0F3, body text #73879C,
     headings #2A3F54, accents #26B99A.
   - OVERFLOW GUARD: each card's main container must have width: 100%, box-sizing: border-box.
     For lists or tables with long text: min-width: 0, white-space: nowrap,
     overflow: hidden, text-overflow: ellipsis.
   - Support an orientation attribute ("horizontal" / "vertical") via Flexbox or CSS Grid.

3. ICONS & UTILITIES:
   - Include an ICONS object with raw SVG from Lucide Icons (stroke="currentColor",
     stroke-width="2", no fixed external dimensions). No CDN font libraries.
   - Include helper functions for currency (es-PY, PYG) and dates as needed.

4. COMPONENTS TO GENERATE:
   - <wc-[module]-summary>: Executive banner with dark background (#2A3F54), full width.
   - Specific components for each logical section in the JSON (counters, progress bars, KPIs).
   - <wc-[module]-last-updated>: Compact, elegant sync timestamp display.

5. DJANGO DELIVERABLE:
   - Full HTML block structured inside <div class="container-fluid">.
   - Use Bootstrap rows and columns (col-lg-*, col-md-*, col-sm-12) for clean layout.

Here is the JSON data:
[PASTE YOUR JSON HERE]

Prompt: Restyle Django Templates

Act as an expert Frontend developer specializing in UI/UX and corporate web interfaces.
Your goal is to restyle an existing Django template with a modern visual design,
without altering its logic, server-side tags, or control structures.
Work entirely within the HTML file, 100% self-contained (NO {% include %} tags).

Rules:

1. ABSOLUTE RESPECT FOR LOGIC:
   - Do NOT alter Django tags ({% extends %}, {% block %}, {% csrf_token %}, etc.).
   - Preserve all functional IDs and form attributes.

2. COLOR PALETTE & CSS (injected in {% block head %}):
   - Background: #ffffff | Borders: #E6F0F3 | Text: #73879C | Headings: #2A3F54 | Accent: #26B99A
   - Required classes: .gt-content-wrapper, .x_title_modern, .x_title_left,
     .x_title_actions, .table-responsive-modern, .modern-datatable, .gt-table-actions

3. TITLE CONSISTENCY & RESPONSIVENESS (REQUIRED):
   - .x_title_modern: display flex, flex-wrap wrap, gap 15px, justify-content space-between.
   - Left side (.x_title_left): flex 1, min-width 250px. Contains icon wrapper and <h3> title
     (uppercase, bold, #2A3F54 !important, word-break: break-word) plus a descriptive <p>.
   - Right side (.x_title_actions): reserved for buttons; always present even if empty.

4. TABLE STRUCTURE:
   - Wrap tables in <div class="table-responsive-modern">.
   - Table tag: class="table table-striped table-hover modern-datatable".

5. DELETE/CONFIRM VIEWS:
   - Center form container using grid classes (col-md-10, col-lg-8, mx-auto).
   - Limit form container to max-width: 70% on large screens.
   - Use clear visual alert style (accented left border, soft background).

6. FORMS WITH MODALS, SELECT2 & DATEPICKERS (REQUIRED):
   - Forms inside modals must initialize widgets on shown.bs.modal, NOT document.ready.
   - SELECT2: always use dropdownParent: $('#modalId') inside modals. Never initialize
     on elements with .select2-hidden-accessible.
   - DATERANGEPICKER: use moment.js daterangepicker with singleDatePicker: true,
     autoUpdateInput: false, format DD/MM/YYYY. Listen to apply.daterangepicker event.
     Do NOT use Bootstrap Datepicker — it's not available in this project.
   - If the form has tabs, initialize ALL widgets when the modal loads, not just the active tab.

7. DELIVERABLE:
   - Return the complete HTML, clean and ready to copy-paste as a single professional file.

Here is the current template to restyle:
--- CURRENT TEMPLATE ---
[PASTE YOUR TEMPLATE HERE]

What I've Learned So Far

The good:

I can write application logic at full speed without worrying about styling. I build the functionality, then hand the templates to the AI for the visual layer. It's a clean separation that genuinely speeds things up.
The context/study stage often surfaces technologies or approaches I hadn't considered. It's not just about getting a task done — it's also a learning moment.
A well-maintained session URL is like a project memory. Come back a week later, paste the URL, continue from where you left off — no re-explaining needed.
Having the model write the prompt (instead of writing it myself) means the prompt is compatible with other models too. Portability matters.

The constraints:

Every AI-assisted workflow requires an upfront context stage. There's no shortcut. The quality of the output is directly tied to the quality of the context you provide.
Refinement is ongoing. The first version of any prompt will miss things. You have to run it, see what breaks, and add clauses. Iteration is the process.
The session is your source of truth. Keeping everything in one conversation — or at least saving the URL — means you always have a recovery path when something goes wrong or new code needs to be integrated.

Final Thought

This workflow won't suit everyone. It's opinionated, it's centered on Django web development, and it assumes you're willing to invest time upfront in the context stage. But for me, it's changed how I work — not by replacing my judgment, but by letting me move faster and stay focused on what actually matters: the logic, the data, the product.

If you have a different workflow, I'd genuinely love to hear it. That Telegram question is still open.

推荐订阅源

DEV Community