Last week two things happened:
I asked myself: How much of this could be done by AI?
First, I drafted the proposal to answer the bid (link) using Claude AI. I’m not going to create a winning proposal. I can’t get this work. I don’t know R and I don’t have any projects with R experience. Nevertheless,a project like this can’t be won if one doesn’t submit a proposal.
Second, I took the project details from the Code With Us post and had Claude AI draft a project requirements document (PRD) ( link ). If the project details were accurate and descriptive, the PRD should reflect what’s involved to build this application.
Third, I built the app. I don’t know R. I have almost 45 years of coding experience, so I know how to get a grasp of a technology that I don’t understand. I know what questions to ask. I took what little I knew. I combined that with a new Github code repository ( link ). I opened up the OpenAI service, Codex and began the code generation. It took several rounds of steering the code, but in the end I had a working application written in R. I put it up in a deployment environment and tried it out. It works. It’s important to note that this works according to the plan and a plan built according to the marketplace opportunity. In a real world use, it may fall short of what’s needed. If it does come up short, the planning step can be re-evaluated and the code build can be re-run.
This isn’t the first time I’ve used Codex to build code. I have used it to quickly build WordPress plugins and apps. I have used other systems like Claude, Loveable, Bolt and Minimax, and Grok to build applications. These AI systems work great to build applications quickly. They all need good planning and oversight, but they can all turn out good code.
In a cash strapped world, we need to find ways to do things better and faster. I used artificial intelligence to write a proposal for this $16,000 project; write a plan; implement that plan; and deploy the application in something like 3 hours.
An application development project can be described as having three components:
Using Artificial Intelligence (AI) to develop applications is sometimes called “Vibe coding.” Almost all of the development is left up to the AI. Taken to the extreme: the planning, development and viability can all be turned over to your favourite AI builder.
Organizations ranging from private industry through to national governments are looking at AI and wondering how it can help them. How AI can speed delivery; drop the headcount in their organization; and/or deflate the budget requirements. AI can accomplish all three.
Planning, development and the application viability could be thought of as a three legged bar stool. If not built right, that bar stool will be a disaster to use. When building a project, these three elements can compete for a finite well of time, money and attention. Short-changing one element, can force the other elements to balloon to cushion the shortfall. It’s the adage of “you can have fast, cheap or good– pick two.” The competing priorities could live in harmony. At the same time, they could be faster, cheaper and better. Pick all three?
Maybe we don’t need to build project bar stools. If we break down these parts of a project when armed with AI, project completion could look very different.
Planning doesn’t need to be a formal, drawn-out process. In the most simple terms: it’s the headline. What should the application do? What should it work with? What does it do?
Project planning captures the timeline, specifications, diagrams, and details and anything to trap the elements of the project. This planning includes the user interface (UI), the user experience (UX) and a firm picture of what work the application does.
Planning is the most important and least visible part of an application. My personal experience: if a project is exhaustively planned, it can land on a dime. All of the pieces make sense. All of the details are captured. All of the stakeholders appreciate the project.
It’s pretty clear that planning is sometimes skimped out. Many programs show up full of holes. The functionality doesn’t work. There are glaring security holes. They just don’t work.
From a programmer’s perspective, the development is “the work.” We know better, but for all intents and purposes, the programming appears to be the work. Without the code, all you’d have is great planning documents. It often takes up the lion’s share of the time and budget involved. If the planning is clear and succinct, the development phase will be the majority of the project. If planning is shortcut, the development goes from a smooth ride to bumpy disaster. Questions arise. Vagaries fester. It plays out the phrase, “If you fail to plan, you plan to fail.” Inadequate planning will drag out a project. Development without a plan can be an expensive, exhausting exercise in frustration.
A plan is a good idea. Development is the realization of that plan. Viability: it’s how the project goes out into the world. UI and UX from the planning phases hits the screen. Does it work? Do the users make sense of it? If people dislike the interface, they won’t use it.
Beyond the look and feel, the really big consideration: security. As code does more things– more connectivity, more utility and more performance– there are more opportunities for problems that arise from security holes. Can the logins be faked? Can the data be scooped? Can financial and personal data be siphoned out of the application? An attractive app with big security holes is radioactive.
Assume the application is pretty and all of its security is locked down. Will it work long term? There is a concept called “technical debt.” Technical debt are the awkward parts of launching a program. Can the program be added easily by the user? Is its data portable when needed (migrating to a new device; or restoring a backup)? Can the program be upgraded as needed? Will the code work with newer operating systems? There are thousands of fantastic programs, plugins and tools that worked on old computers, but die on anything from the 2000s. When an application works but hides fussy elements– that application isn’t going to flourish.
After the coding is all done, the other front of viability: adoption. Marketing, documentation, support and marketplace fit are all challenges to the longevity of an application. If a great product is also an unknown product, it’s eventually doomed through a lack of adoption.
Good planning, smart development and lots of testing will expose issues. Viability comes down to the survivability of the application when it goes out into that big cruel world.
People are still confused about how artificial intelligence works. While touted as intelligence, what it really does well is a colossal exercise in auto complete. Give a chatbot a prompt and it runs with it to satisfy the prompt. Chatbots have indexed massive amounts of programming code from other available projects. They can use that code as an example of how to build new code.
AI works very fast. In the last year, AI gained the capacity to work long. It can take on increasingly larger projects, spending the time to code elaborate solutions. The OpenAI service, Codex, is capable of developing very large and elaborate applications. It can store its code in a code repository– a storage tool to track changes and manage the sharing of the code between developers.
At its core, AI is a computer system: it needs explicit direction to do anything. AI is fantastic at filling in the blanks but those blanks are where variability can creep in. The solution is to be exhaustive on the details. AI can take in a very large set of instructions to work from.
Our workflow: we write a detailed product requirements document (PRD). It outlines what the project needs to succeed. We build that with Claude, iterating the project plan until it’s detailed enough for a developer to work with. If it’s good enough for a developer, it’s good enough for an AI. We hand that PRD to Codex and ask it to develop the application drawing from the PRD details. After the work is detailed, we do a combination of manual and AI driven code reviews. We draft security documents to cover testing and find issues that could threaten the success of the application and the security of its data.
Before the chatbot era, development step took the lion’s share task of a project. A deep planning exercise was always good, but it could be abbreviated by personalities and budget pressures. No one wants to short change the security and viability aspects, but those aspects get squeezed just to get a product out the door. What resulted were applications that did the work, thin on planning and band-aided security.
AI flips the script. The biggest component– the development– can be handed over to Codex and similar tools to build the code. That bulk can be externalized. The work happens much faster. It can happen better. It can be coded at an expert level. The found time and found budget can go into planning to get a clear target. The breathing room can go into the viability topics to ensure it’s safe, it’s appreciated and its utility has some longevity.
The BC government’s Digital Marketplace posted a $16,000 opportunity. Depending on billable rates, $16k ranges from 320 hrs. of development at $50/hr.; all the way to 80 hrs. of development at $200/hr.. That 80 – 320 hours of development time should cover planning, development and security / viability. It will likely be a 25%-60%-15% split of where the hours go. Arguably, the majority of any budget goes to the development phase. What happens to project labour breakdowns if the majority of the work can get replaced with AI?
Imagine if the project splits were to radically change:
Beyond re-cutting the resource pie, shrink the pie. Look at the $16k project above. If they forecast that 60% of the project or $9600 went to development, but that could be done with a few hours of vibe coding and a strong requirements document– then a project needs less time to deliver. Replace that $9600 bulge with 12 hours of development; precede it with 24 hours of planning; and follow it with 24 hours of viability work. Use AI to get more out of the planning work; and then get more out of the viability steps at the end of the project. Maybe a $16k project could become a $10k project delivered faster and better thanks to AI. That’s a savings. Wherever there is knowledge work (coding, number crunching, etc.), AI can play a role in delivering that work better, faster and for less money. The delivery comes down to skill.
Organizations look at AI with technological superstition. They think it will simultaneously take all the jobs and do the work poorly. Some organizations have laid off people or stalled hiring because they’re replacing people with AI systems. Those organizations have seen minimal wins. They’re missing the role of AI.
AI in the workplace is not about replacing people. It’s about enhancing them. Think of a good suite of AI tools and techniques as an Iron Man suit, not a robot worker. Your people could do more, do it better and do it faster. That found time can be sunk into making solutions that are more ruggedized and well tested.
Organizations looking to deliver more for less need to look at what artificial intelligence can do to help. Imagine if the BC government could deliver its IT projects for less money? That’s not going to knock down the tremendous BC government deficit, but every little bit helps.
