Week 2: No Code February

Week 2 was all about remapping a code approach to an AI code approach, with little learning lessons. Big insights are on the value of planning prompts to get better outcomes.

This was a huge week for my “code brain” re-education. I have been coding and building solutions for 20+ years, and for every startup and challenge, I have applied similar patterns: I select the tech language I know, the data store I know, and the hosting/cloud provider I know.

No code. February is a month-long experiment in breaking this pattern.

So, while I am not writing code this month, I am delivering code. This could seem like a spitting of hairs, but it is different. I am using AI tools to write the code. I prompt the AI to build the app and code the required structure.

I was asked this week if a non-technical person could do the same. My answer is both year and no. Yes, if you want to take the time and learn the terms needed to tell an AI what you want built. Terms like routes, redux.

No, if you are thinking of a “one-shot” prompt to get the app you want. I have not found any AI tooling solution to infer from a single sentence or even a one-page outline of features to build an acceptable app.

But neither can a human. Tech teams are composed of product owners, project managers, and developers. We would not have Agile, scrum, or Kanban development frameworks if a single request could be converted into a feature.

So, asking an AI to do this is just bad lazy thinking.

Insight #1: Prompt Framing

Using Bolt, I quickly learned that I needed a starting point and outline for how I wanted to ask for an application. Details are good, but they should not be upfront. A single Uber prompt is a waste. I have had the most success by treating the AI like I would a friend in a conversation over a beer. I frame the issue and problem in loose and general timers.

Insight #2: Framework Specific

I received much better results when I started by adding a specific framework (react/nest/next/svelt) term to the prompt. For example, if I added “react” or “next.js” to the term, the AI would be better able to set up the initial file structure using patterns common to applications in the framework. AI tools like Bolt.new will actually build out all the application structures: components, routes, and store folders. Once these patterns are set, they contribute to the following response, so getting them right is important.

Aside: I have had to stop and restart a few times when I found that my prompts contained logical inconsistencies, generating base code that was too confusing (to the AI) to be correct.

Insight #3: Github Is Key

Not all AI tools have full integrations with Github. Bummer! This was an issue until I found a Chrome Extension that bridged the feature gap. Bolt to Github - a Chrome extension that shims in the option to push a code base to Github was a huge win.

This extension adds the ‘Github’ Button to the Bolt AI webpage. This allowed me to save and commit as needed, and if the AI scrambled the code, I would not need to start from again. The AI will get lost. One or two bad prompts and blam.

Insight #4: Speed of Prompting

Prompt and wait. The bigger the prompt, the more work the AI had to do and the longer it took. It makes sense. If I had a developer with several 5-point agile tickets, the developer would need to process the work in series if the tickets depend on each other or are contradictory.

Complexity slows down humans and AI equally. For AI, the slowdown is apparent in the wait times (between prompts) and the number of tokens consumed. Using a single AI tool for everything led to me burning 3.5 million tokens in a week!

But! I did generate 1.5 weeks of work in 2 days! Winning.

Final Insight: Use more than one AI Solution

This week, I am branching out using Bolt.net. This month, I have used a few of the tools to find different models to solve different parts of the application development process. Bolt.net is clearly great at front-end apps but not so great at the server side. While it can write Node.js Express code, it’s not good at it. 

Henry Shi’s post on LinkedIn outlined 15+ different solutions. Almost too much to process!

A Founder Perspective

If you are a founder reading this, what is the takeaway? Why should you care about a developer who is training in AI? How does this help you with your startup?

Hiring! Hiring just got harder. How are you going to find a technical co-founder or hire an initial team and know what you are getting: AI-enabled or legacy coders implementing old patterns? I have no good answers yet.

The Gen AI big bang from the fall of 2022 is still remaking the industry, and the new tooling is still in its infancy. I think founders need to get into the weeds of the problem they are solving and stay in the weeds.

What’s up Next Week?

It's simple. I am delving deeper into the AI rabbit hole. This week’s gains were huge, and I am still processing them. Next week, I will work with Loveable. I need to find alternative solutions for specific applications that every client needs: admin tools and Automation Configurations. 

If the week does not turn into a work washout, I will also dig into DataButton. DataButton claims to be the CTO replacement, so….