Project Initiation Indecision - 2026 Edition

- by Mark Bowker

I've started plenty of projects in my time. All of them have brought an element of indecision (not helped by my own over-thinking nature).

  • Which framework should I use?
  • ORM or not to ORM?
  • Data Structure A or Data Structure B?
  • Which over-engineered interface should I go with, Just In Case™?
  • How many transactions-per-second can the DB handle [for my single-user TODO list app...]?

But a new dilemma has entered the ring as part of this Royal Rumble of decisions:

What, if any, portion of the code should I write by hand?

In contrast to the black-and-white snarky responses that social media would have you believe, this was more nuanced than I expected and gave me real pause for thought with a recent project I wanted to take to the next level following a few rounds of prototyping.

What is your current experience and skill level?

Even this initial basic indicator is multi-layered: In the domain? With the language? With the framework?

A perfectly reasonable response would be "in order to learn, you must do. To improve, you must make mistakes". Yeh, sure, fine. Totally understandable and I agree... in general.

In my situation, I had only a middling-to-low level of experience with many of the technical layers. Sure, I'd worked with them individually before, but not to the level of building my own releasable projects with them.

(The domain actually isn't a concern here. If you're unfamiliar with the domain or problem you are trying to solve, you shouldn't worry about this and should simply do whatever is necessary to cover those unknowns first, such as rapid prototyping.)

I had already done my initial prototyping. I had already generated my slapp[1]. I was ready to proceed with something a real user could use.

I am a skilled engineer. I have plenty of experience developing and supporting software applications. But this situation mixed in with AI was new to me.

What are you trying to achieve?

Am I trying to continue deep-diving into the language/frameworks/libraries so that I become a better reviewer of generated code? Probably not. I have probably written enough with this framework to have a general understanding of the moving parts. I have not written enough to have good judgement about whether something is written well or not.

So should I continue hand-writing most of the code to build up that on-the-ground intuitiveness?

Will my below-par judgement affect my reviewing of AI-generated code? Am I just laying poor foundations for something I would like to build on?

Will using AI from the beginning lead to my later inability to make changes, or otherwise understand what's going on?

What if...?

Breaking the death-cycle of indecision

Well done. We've asked a bajillion questions, each one producing a gazillion more. We've achieved nothing. Lines of code written: zero. Congratulations, me.

To many, this would have been a silly exercise in over-analysis. And they wouldn't be wrong. But every engineer is different, and every engineer is trying to re-familiarise themselves with this new world in all the different situations we find ourselves in.

In my day job, I'm very comfortable with the use of AI. I have a feeling for the edges of its capability. The systems and architecture are already established and a lot of the work is additive. Changes are generally small and manageable. I know what I want from it, and I (usually) know how to get from it what I want.

What is new for me, though, is how to use AI within a new project that uses a less familiar stack.

Hence, I'm taking the following guidelines as an experienced engineer working on a new project trying to achieve something somewhat novel but with technologies that are somewhat unfamiliar.

  • Core is core. Interfaces and data structures here should probably be hand-written first. Get a tactile feeling for them. Do they feel right? Use AI to spike up clients using these interfaces and structures to see how they feel. Do the clients feel sane? If not, iterate. Keep core separate (ports and interfaces, etc etc).

  • Lean towards popular, batteries-included frameworks. Less code should need to be produced and reviewed. Less decision fatigue for non-valuable choices.

  • Jump in sooner rather than later. In my day-to-day work, I find that if the AI has not really done something satisfactorily or has just done it plain wrong first time round, I will re-approach the problem with it more as an evaluation exercise to try and improve my own working with the AI. I.e., I'm less likely to just jump into the code and fix it myself. For this project, though, I should not do that. If something isn't quite what I wanted, go into the code immediately. Use that as an opportunity to get hands-on.

  • Sketch heavily. Data structures, flows, interfaces. Use AI to sketch them out and conjure up alternatives.

  • Keep it small. For comfortable projects, you can let AI loose on larger features because you already have an expectation on quality and delivery. If you don't, you really need to fight the temptation to just let sloppy code slide. And the only way to do that is to keep generated code to a minimum.

  • Actively refactor. By actively here, I mean both by yourself and by using AI to work through refactor options. Spike and sketch as necessary.

There is nothing new here. What it is, though, is just trying to set each of the dials at the correct setting for the situation and tweaking as necessary. That is what experience is all about.

But there is a downside here. I am using AI heavily for this workflow. In fact, it is AI-first. This is an accepted trade-off, but it is a trend I am slowly finding myself moving towards. The key idea I'm sticking to is to ensure that all generated code stays well within the bounds of my understanding, with the acceptance that I won't quite get that deeper knowledge that I may previously have expected to obtain.

In general, this is much slower and tougher than my day-to-day bread-and-butter work, but this generally helps me stay engaged and continue to learn a stack I want to get more accustomed to.

For this particular situation, I think that's okay.

And I'm okay with that.

Let the coding commence.

Footnotes

[1] slapp: slop app