const existing = context.db.get('bank_accounts', userId);

if (existing) {
return {
statusCode: 200,
body: {
ok: true,
data: {
account: existing,
alreadyOpen: true,
},
requestId: context.requestId,
},
};
}

const account = context.db.put('bank_accounts', {
id: userId,
balance: 0,
});

No overengineering. No guesswork. Just exactly what was asked.

Even better — the AI added small, useful touches:
• createdAt timestamp on records
• Clean, consistent response structure

This is the sweet spot:
• Fast to generate
• Fast to review
• Easy to trust

Less noise. More signal.

Day 20 ⚡

The impact of tighter prompts is really starting to show.

The generated code this time was:
• Focused
• Simple
• Easy to review
• Directly aligned to the request

Here’s a snippet 👇

#buildinpublic #ai #nodejs #softwarearchitecture #api #systemdesign

Here’s the prompt 👇

“Context: Working in a new app ‘bank’
Given an API endpoint /bank/open that creates a new account

Behaviour: a new account is opened, with a db entry for the user that contains just a starting balance of 0
Constraints: No breaking changes. Keep focus tight. Minimal implementation.
Return: Specific change. Rationale. Updated response shape.”

That’s it.

What this enforces:
• Clear intent
• Minimal scope
• No overengineering
• Structured output

Instead of letting AI design the system —
I’m guiding it step by step.

Early signs?
Much cleaner. Much more predictable.

Sometimes the fastest way forward…
is slowing things right down.

Day 19 🏦

Time to test a tighter, more controlled approach.

New idea:
A hypothetical bank app — built from scratch, one API at a time.

No big prompts.
No open-ended design.
Just focused, incremental development.

#buildinpublic #ai #softwarearchitecture #nodejs #systemdesign #api

The gap 👇
The apps sitting on top are much less defined.

This is where the AI has:
• Drifted from intent
• Overreached in its implementations
• Stopped behaving like a “pair programmer” and started guessing

So — time to adjust the approach.

A focused prompt style:

Given this API endpoint /orders/{id} that fetches order details,
current behavior: returns full order object with nested items and customer info.
Improve for: contract clarity.
Constraints: no breaking changes.
Return: specific change, rationale, and updated response shape.

This forces:
• Clear scope
• Defined constraints
• Structured outputs

Less ambiguity → less drift.

The lesson?

AI works best when you treat it like a precise tool —
not an open-ended idea generator.

Now let’s bring the apps up to the same standard as the platform.

Day 18 🎯

Taking a step back and reviewing the system as a whole…

The good 👇
The magic monolith itself is holding up well.
The core design is sound and well documented.

#buildinpublic #ai #softwarearchitecture #nodejs #systemdesign #devworkflow

(Note: I am not sponsored by railway, just seeing what it’s like to deploy to.)

Railway Railway is a full-stack cloud for deploying web apps, servers, databases, and more with automatic scaling, monitoring, and security.

So I asked:

“context: I would like to deploy the entire project to a commercial service like railway.com
request: please can you review the project and plan what changes may need to be actioned”

The result? 👇

• A concise, structured list of actions

• Clear identification of what needs changing
• And importantly, where those changes need to happen

No fluff. Just actionable steps.

This is where AI really starts to shine:
Not just building… but helping you think through the next move.

Next step: turn that plan into a live deployment.

Day 17 🚀

One thing that’s becoming really clear:

AI isn’t just a coding tool —
it’s just as valuable for planning and understanding.

Before going any further, I want to test this system for real

#buildinpublic #ai #softwareengineering #deployment #nodejs #systemdesign

And that’s where Copilot AI fits in 👇
Used properly, it doesn’t replace engineers —
it enhances our ability to deliver.

Faster builds.
Quicker iteration.
More time spent on the actual problem.

That said — challenges still remain:
• Keeping architecture aligned
• Managing drift
• Ensuring long-term maintainability

Next up:
Extending the service further… and getting it deployed.

From ideas → running systems.

Week Wrap 🚀

A good week.

Lots of progress — and AI has been a big part of that.

It’s easy to forget:
Software engineering is about delivering solutions.

Coding is just one piece of the puzzle.

#buildinpublic #ai #softwareengineering #nodejs #systemdesign #devjourney

What it looks like:
• Zero external dependencies
• Single app.js powering everything
• Basic but usable UI for interacting with the game

Is it perfect? Not even close 👇
• The single file approach isn’t very maintainable
• Structure is minimal at best

But that’s intentional.

This is about rapid, dirty iteration — not something public-facing.

And in that context?

It’s a huge win:
• Instant feedback loop
• No dependency headaches
• Massive time saver

Exactly what I needed at this stage.

Latest output here:
github.com/andymonis/aw...

Speed now, structure later

Day 16 ⚡

This one surprised me.

Within 5 minutes, I had a fully functional PoC web UI up and running.

It’s more than just a test harness…
but only just 😅

#buildinpublic #webdevelopment #nodejs #frontend #ai #rapiddevelopment

So the focus shifted 👇

Not a public-facing app.
Not over-engineered UI.
Just a functional mobile web app using HTML5.

The prompt:

“context: working within the cranked app, there is a need to have a specific mobile web app…

keep external libraries to a minimum…
aim for a single HTML page for testing…
design: Home, Deck, Event screens…”

Key principles:
• Minimal dependencies (avoid bloat + compatibility issues)
• Single-page test app for fast iteration
• Clear structure:

• Home → status + results
• Deck → manage cards / hand
• Events → choose actions

This is about control and clarity.

Before building a “real” frontend,
I need something I understand, can tweak instantly, and won’t fight me later.

Build the simplest thing that works —
then evolve it

Day 15 🧪

At this point, I realised:

I don’t need a polished frontend yet —
I need a test harness I can actually use.

Something simple.
Something maintainable.
Something that lets me interact with the system quickly.

#buildinpublic #webdevelopment #nodejs #gamedev #frontend #devexperience

The AI has done some genuinely good work 👇
• Built out features quickly
• Suggested useful improvements
• Kept momentum high

But it’s also introduced a lot of noise:
• Extra code paths
• Unclear structure in places
• Decisions that don’t always align with the original intent

And this is where it gets interesting…

It starts to create a sense of detachment as the developer:
• Who actually owns and maintains this code?

• Is it truly understandable?
• Does it still map to the architecture I had in mind?

For a PoC?
This is fantastic. Speed over perfection.

For production?
That’s a different conversation entirely.

The challenge now isn’t building faster —
It’s building intentionally.