There doesn't seem to be a day that goes by without a post or article stating that "Low-code is dead", and while this isn't true, with AI development things are definitely changing.
Although working in low-code tools like the Power Platform is my job, in my spare time I like to pretend to be a pro-coder, and with AI tools now at a level that I can almost not pretend.
So this blog is all about how I do AI development, its probably not the right way, or the best way, but it works for me.
- My Skill Base
- My Setup
- How I Build
1. My Skill Base
As I said, I'm not a pro-code developer, but I know a few things. And I think it's important to understand that using AI tools with no understanding only leads to deferred pain. I think there are big differences between AI Development and Vibe coding.
So what do I know:
- Basics of HTML, CSS
- A little more than the basics of JavaScript (I may not be able to write all of it but I can read it)
- GitHub (barely)
- Git Bash, wrangler (barely)
- Cloudflare workers and Pages
- Cloudflare Database and Keyvaults
But I don't
- Understand React
- Use TypeScript (but I could as do use it in OfficeScripts)
- Bother with any sort of build process
- Work on the main branch(unless I want a non-prod instance)
But my mind is like this, React gets built to Html/CSS/JavaScript, so why not skip a stage and get the AI to just build it direct.
2. My Setup
I'm not into CLI's that much, so no Claude Code, and Cursor is expensive, so that leaves good old VS Code (plus I get GitHub Pro as an MVP reward 😎). The output window is ok, but I don't just read the agents outputs, I like to see the code, so it works for me.
I'm a Opus man, infact Opus 4.5 was when I felt confident to move beyond AI Assisted Development to full AI Development. 4.6 is better but not significantly. If Opus is having a bad day I will get Codex 5.3 ago (looking forward to testing 5.4), and Gemini 3/3.1 is worth a go when you want something more visually creative. But 9 times out of 10 its Opus for me, but that's more of a personal preference, as most of the top models and some open weight are perfectly good enough.
One of the most important things I think you need before you start AI development is an instruction file. This is like a custom prompt that you use to ensure the agent works the way you want. It shouldn't be too big, and I personally don't let the agent write its own.
My instruction file covers a few things but the main ones are:
- Naming convention
- File structure
- Language preferences (as example Opus like JavaScript var's, where I'm a let guy)
- Coding preferences
The last one is the big one, I like my the LLM to work in small units, building in function blocks. That way changes are often contained, it's easier to read, and everything is reusable.
This is my current instruction.md file:
# Copilot Instructions for AutoReview Pro
These instructions guide AI coding agents working in this repository to be immediately productive and consistent with project conventions.
## Project Overview
- standard web technologies: HTML, CSS, JavaScript (ES6+).
- Core files:
- `index.html`: Structure, assets, and script/style inclusions.
- `styles.css`: responsive and built to light/dark themes using CSS custom properties.
- `script.js`: key functionality of the site
- `dom.js`: dom manipulation functions
- `imgs/`: image files for UI icons.
- `README.md`: Features, usage, and future enhancements.
- `Sitemap.xml`: for search engine indexing.
- No build step.
- Create as a Progressive Web App (PWA) with service worker for offline support and caching, but with always fetching latest data when online.
- cloudflare hosting
- Follow these naming conventions:
- Use camelCase for variables and functions.
- Prefix variable names: `b` boolean, `i` number, `s` string, `a` array, `o` object, `e` element.
- Ensure variables are type consistent and avoid implicit type coercion by using naming conventions.
- CSS should be in a separate file, avoid inline styles unless for dynamic styling.
- JavaScript should be in a separate file, avoid inline event handlers and scripts in html.
- JavaScript files should follow: script.js for main logic, dom.js for dom manipulation functions, specific js files for large logic, and per html page for page-specific logic.
- Function-first approach; avoid classes unless necessary.
- Build functions for reusability and testability.
- Use descriptive names for variables and functions, avoiding abbreviations.
- Use let and const, avoid var.
- Use const for dom elements where possible.
- Use `//` for single-line comments and `/* */` for multi-line comments.
- Use forEach, map, filter, reduce for array operations instead of for loops where appropriate.
- Use arrow functions for anonymous functions and callbacks.
- Use " for html attributes and ' for js strings, ` for template literals.
- Use `new RegExp("pattern","flags")` (avoid literal `/.../flags`).
- Use `fetch` for API calls, with async/await syntax.
- Handle errors gracefully with try/catch and user-friendly messages.
- Follow the existing code style and conventions in the project for consistency.
I also have a few skill.md files for specific tasks (skills are similar to instructions but the LLM uses them when necessary), my favourite example is frontend-design skill from Anthropic.
https://github.com/anthropics/skills/blob/main/skills/frontend-design/SKILL.md
This is an example of a prompt I will use to help start:
create me 5 landing pages for my website. the site provides training, consultancy, and custom builds. Each site should be creative and unique, they should follow a modern design. To aid review create a way to navigate between the 5 pages. Make sure you use the frontend-design skill.
You can see them all live here
3. How I Build
My approach to using AI is to use it very much like a tool, I want it to do a specific thing. This means the scope and outcome if focused and generally small. Over time and with improvements of the models I've felt more confident in increasing the size and complexity of the thing.
In my mind this evolution can be broken them into 2 categories, AI Assisted development and AI Development.
AI Assisted means that I lead the agent a lot more, I normally prompt at a function level, and then I review the output and then link everything together by hand. The reason I like this is:
- The context is small for the LLM so its normally better results
- Its contained so easier for me to review
- As I'm doing the linking and using I still understand everything
A good example was when I was building my code review tool AutoReview-Pro, I had a lot of JSON data that I wanted represented as HTML tables, so I used this prompt
Create me a function for converting JSON to HTML, I will pass in 2 arrays. The first will be the array of data, the second will be configuration. Each item in the configuration will represent the columns in the output, each item will have these keys: Name - field from the data array, Display name - name of the column in the header, Width - width % for the column, Link - field to use when clicked, this is optional and if not included it should not include a link
After reviewing the function and testing it I then used it in my code where I wanted it.
But as the models have become more powerful I have felt more and more confident moving to AI Developed. You can think of this as the next level up, where the scope of work increases and the detail in the prompt decreases. I now want to create a piece of functionality/value in the project. A good example would be:
I want the users to be able to download the entire collection. The button should be next to the edit collection button. The output should be a postman collection file and be downloaded to the users device. Use the toast function to update user with success/fail messages.
As you can see the piece of work is now:
- Larger scope - updates 3 files: JavaScript, HTML and CSS
- Less involvement by myself - it links everything together
- Simpler prompt - half the length
There is trade off that it's harder for me to review the output, and I'm more inclined to be lazy and just trust it. So there is potential for some tech debt in there and missed dege cases, but it moves me from being 5x faster to 20x faster, so I would say it's worth it.
In both use cases I have a golden rule, which is "I do small updates". If I need to update a colour of an item, I go into the CSS and edit it, if I want a button moving, I moved it. This is because there is minimum time saving, it removes the risk of double code and it forces me to understand the code based.
Double code - this is one of the biggest issues I see with agent generated code, the agent solves a problem in 2 different ways (e.g uses CSS and JavaScript when solution only needs one), this makes it hard to read, really hard to debug, and can generate bugs when the 2 different ways clash.
There is also the elephant in the room with AI development, Vibe coding. Do I vibe code, yes, but do I do it for anything important no.
In my view the main difference between AI development and Vibe coding is scope and understanding.
Whn vibe coding I scope everything to the agent, and I don't understand the output. If I was to ask a agent to create me a app that did x, it would most likely:
- Create a React App - I can't develop in React
- Design/architect in a way that I'm not use to
- Build to its training, so generally make something that looks AI generated
So when I do vibe code I ensure my instruction.md file is used, that at least means it builds in something I can develop in and generally the way I like it.
I also don't do it for anything important, anything where if it broke I would be in trouble if I could not fix it.
And that's how I now build, when I look back at the last year and some of my projects and the level of AI involvement, its crazy.
Flow Utilizer - 100% me
AppReview-Pro - 80% me
AutoReview-Pro - 50% me
Power Platform Undoc - 20% me
And look at those sites, it's hard to argue against the agent being a lot better at building then me.
Top comments (4)
Amazing job David, thank you for sharing it! WIll give it a try myself!
Some comments may only be visible to logged-in visitors. Sign in to view all comments.