Forem: Gleno

What's your stack?

Gleno — Sun, 22 Mar 2026 23:52:43 +0000

So I asked chatGPT to list my core "AI-assisted coding" stack items and what they are and it went waaaay overboard. I think it thinks I'm a moron.

What's your stack? Is the below stack really the best combination (chatGPT seems to think so)? If anybody wants to add their stack in the comments, maybe just do it in one line, like chatGPT did right at the end: myStack=TypeScript + React + Next.js + Tailwind + Supabase + PostgreSQL + Vercel with Tauri added when I want a desktop app.

The core stack items

1) JavaScript

What it is: The core programming language of the web.

Used for: Frontend and backend code.

Think of it as: The foundation everything else sits on.

2) TypeScript

What it is: JavaScript with static typing.

Based on: JavaScript.

Used for: Safer code, better autocomplete, fewer silly mistakes.

Think of it as: JavaScript with guard rails.

Rule of thumb: TypeScript is usually the better default for app projects.

3) React

What it is: A UI library.

Based on: JavaScript / TypeScript.

Used for: Building screens, components, forms, dashboards, and reusable UI pieces.

Think of it as: The system for building the visible parts of an app.

4) Next.js

What it is: A full-stack framework built on React.

Based on: React.

Used for: Routing, layouts, server-side logic, app structure, and production-ready web apps.

Think of it as: React plus the app framework around it.

Simple view:

React = components

Next.js = complete app structure

5) HTML

What it is: The structure of web pages.

Used for: Markup and page content.

Think of it as: The bones of the UI.

6) CSS

What it is: The styling language for the web.

Used for: Layout, spacing, colours, typography, responsiveness.

Think of it as: The visual design layer.

7) Tailwind CSS

What it is: A utility-first CSS framework.

Based on: CSS.

Used for: Fast, consistent styling directly in components.

Think of it as: A quicker, more structured way to style apps.

8) Node.js

What it is: A JavaScript runtime for running code outside the browser.

Based on: JavaScript.

Used for: Dev servers, build tools, package scripts, backend code.

Think of it as: What powers the development/tooling side of modern JS apps.

9) npm / pnpm

What it is: Package managers for the Node.js ecosystem.

Used for: Installing libraries and running project scripts.

Think of it as: Dependency management for JavaScript projects.

10) Supabase

What it is: A backend platform / BaaS.

Based on: PostgreSQL.

Used for: Database, auth, storage, APIs, realtime features.

Think of it as: A ready-made backend platform for modern apps.

Important distinction: Supabase is not the database language. It is a platform built around PostgreSQL.

11) PostgreSQL

What it is: A relational database.

Based on: SQL.

Used for: Storing structured application data.

Think of it as: The actual database engine underneath Supabase.

12) SQL

What it is: A query language for relational databases.

Used for: Reading and writing data.

Think of it as: The language used to talk to PostgreSQL.

Easy chain to remember:

SQL → language

PostgreSQL → database

Supabase → platform built around PostgreSQL

13) Auth

What it is: Authentication and user access control.

Used for: Sign in, sign up, passwords, roles, permissions.

Typical provider in this stack: Supabase Auth.

Think of it as: User accounts and access rules.

14) Vercel

What it is: A hosting and deployment platform.

Used for: Publishing Next.js web apps.

Think of it as: Where the app lives online.

15) Tauri

What it is: A desktop app wrapper/framework.

Based on: A web frontend plus a Rust native layer.

Used for: Turning a web app into a Windows/Mac/Linux desktop app.

Think of it as: The desktop shell around a React/Next-style app.

16) Rust

What it is: A systems programming language.

Used for: The native/backend layer in Tauri apps.

Think of it as: The engine under the bonnet of the desktop wrapper.

17) SQLite

What it is: A lightweight embedded SQL database.

Based on: SQL.

Used for: Local desktop storage.

Think of it as: A simple local database when you do not want a full cloud backend.

18) JSX / TSX

What it is: React file syntax.

Based on: JavaScript / TypeScript plus HTML-like markup.

Used for: Writing React components.

Think of it as: The format React code is usually written in.

The default stack combo I’ve mostly been using

Web app / SaaS

TypeScript
React
Next.js
Tailwind CSS
Supabase
PostgreSQL
Vercel

Desktop app

TypeScript
React
Tailwind CSS
Tauri
Rust
SQLite or Supabase/PostgreSQL

The plain-English mapping

JavaScript = programming language
TypeScript = safer JavaScript
React = UI building system
Next.js = full web app framework
Tailwind = styling approach
Supabase = backend platform
PostgreSQL = relational database
SQL = database query language
Vercel = hosting
Tauri = desktop app shell
Rust = native layer under Tauri

TL;DR

If I had to summarise the core modern vibe-coding stack in one line:

TypeScript + React + Next.js + Tailwind + Supabase + PostgreSQL + Vercel

with Tauri added when I want a desktop app.

When the Cure Is the Disease: New Zealand’s Health IT

Gleno — Sun, 15 Mar 2026 01:12:36 +0000

Why New Zealand’s Health IT Systems Are Such a Mess (And Why Fixing Them Is So Hard)

Every time there’s a hospital IT outage in New Zealand, the same question comes up:

How can a modern healthcare system still rely on fragile, outdated technology?

The answer isn’t simple. The current situation is the result of 25 years of decentralised decision-making, legacy systems, and extremely complex integration layers.

To understand the debate around recent digital job cuts at Health New Zealand, you first need to understand the architecture underneath it all.

The Origin of the Problem: 20 Separate Health Systems
The Regional Cluster Attempt
Legacy Systems That Never Die
The Hidden Monster: Integration
National Systems Layered on Top
The Attempt to Modernise
Why the IT Job Cuts Became Controversial
What Hospital IT Architecture Actually Looks Like
Final Thoughts

The Origin of the Problem: 20 Separate Health Systems

For over two decades, healthcare in New Zealand was run by 20 District Health Boards (DHBs).

Each DHB had the authority to choose its own technology stack.

That meant every region could select different vendors for:

Patient administration systems (PAS)
Electronic medical records
Laboratory systems
Radiology systems
Referral platforms
Scheduling tools
Integration engines

The result?

Twenty different ecosystems evolving independently.

Some DHBs invested heavily in modern digital systems. Others moved more slowly or kept older infrastructure running longer.

When Health New Zealand – Te Whatu Ora replaced the DHB system in 2022, it inherited 20 different IT environments.

Sources:

https://www.health.govt.nz/new-zealand-health-system/key-health-sector-organisations-and-people/district-health-boards

https://www.tewhatuora.govt.nz/about-us/our-health-system/

Think of it like merging twenty companies that all used different ERPs, CRMs, and databases — and expecting them to instantly behave like one system.

The Regional Cluster Attempt

Before the national merger, DHBs tried to reduce fragmentation by forming four regional digital clusters:

Northern
Midland
Central
South Island

Within each cluster, hospitals attempted to standardise some systems.

But between clusters, major differences remained.

Instead of 20 separate stacks, New Zealand effectively ended up with four large incompatible stacks.

Sources:

https://www.health.govt.nz/system/files/documents/pages/national-health-it-plan-update.pdf

https://www.hinz.org.nz/page/nz-digital-health-history

Legacy Systems That Never Die

Healthcare systems are notoriously difficult to replace.

Some hospital software currently in use dates back decades.

Examples seen in healthcare environments worldwide include:

Patient administration systems from the 1990s
Infrastructure built around older Windows environments
Specialist clinical software with extremely long vendor lifecycles

Why not just upgrade everything?

Because healthcare systems cannot simply shut down for migration.

Hospitals operate 24 hours a day, and replacing a clinical system introduces enormous risk.

Source:

https://www.healthit.gov/topic/scientific-initiatives/health-it-modernization

Replacing hospital software is like changing the engines on a plane while it is still flying.

The Hidden Monster: Integration

The real complexity sits between systems.

Because different vendors and platforms are used across regions, hospitals rely heavily on integration standards and middleware.

One of the most common standards is HL7, which allows systems to exchange clinical messages.

For example:

Lab results flowing to patient records
Radiology images linking to clinical systems
Referrals moving between hospitals
Admission notifications sent across services

These messages travel through interface engines and middleware that translate and route data.

Over time, hundreds or thousands of integrations accumulate.

Source:

https://www.hl7.org/about/

This creates what architects often call “spaghetti integration architecture” — a dense web of connections between systems that all depend on each other.

National Systems Layered on Top

Rather than replacing regional systems, New Zealand introduced several national digital platforms that sit above hospital systems.

Examples include:

The National Health Index (NHI)
National screening registers
ePrescribing services
Shared health record initiatives

These systems rely on the regional infrastructure continuing to function.

So instead of simplifying the architecture, they often add another layer of dependency.

Source:

https://www.tewhatuora.govt.nz/for-health-professionals/digital-health/

The Attempt to Modernise

When the government created Health New Zealand – Te Whatu Ora, one of the goals was to finally create a nationally coherent digital health system.

The vision included:

Greater standardisation
Shared platforms
Improved data interoperability
Reduced duplication

However, transforming a system this complex takes many years and enormous investment.

Large health IT programmes around the world have struggled with exactly the same challenge.

Source:

https://www.health.govt.nz/publication/new-zealand-health-strategy

The UK’s NHS once attempted a massive national digital transformation that became one of the most expensive failed IT projects in history.

Source:

https://www.nao.org.uk/reports/the-national-programme-for-it-in-the-nhs/

Why the IT Job Cuts Became Controversial

Recent changes to Health New Zealand’s digital workforce sparked debate.

Critics argued that cutting digital staff could increase the risk of outages because the infrastructure is already fragile.

The government argued the restructuring was aimed at reducing duplication and administrative overhead created when the DHBs were merged.

Sources:

https://www.rnz.co.nz/news/political/589440/documents-reveal-health-nz-knew-it-job-cuts-would-risk-patient-care-hospital-resilience

https://www.rnz.co.nz/news/political/584179/health-nz-confirms-another-major-tech-outage

Both perspectives reflect a deeper truth:

The system itself is incredibly complicated.

Even small organisational changes can ripple across hundreds of interconnected systems.

What Hospital IT Architecture Actually Looks Like

A simplified view of a hospital technology stack might look like this:

Clinicians
   |
   v
Electronic Medical Record (EMR)
   |
   +-----------------------------+
   |                             |
Lab System (LIS)           Radiology (RIS/PACS)
   |                             |
   +-------------+---------------+
                 |
           Integration Engine
            (HL7 / Messaging)
                 |
        National Health Systems
                 |
        Identity (NHI) / Registries

But in reality, each box above often contains multiple systems from different vendors, with hundreds of message interfaces connecting them.

Final Thoughts

New Zealand’s healthcare technology environment didn’t become complex overnight.

It is the product of decades of regional autonomy, vendor ecosystems, and cautious upgrades in a high-risk industry.

Fixing it requires more than just funding or restructuring.

It requires carefully untangling a web of systems that hospitals depend on every minute of every day.

And that is why healthcare IT remains one of the hardest architecture problems in the world.

5ive ways to make good AI code exceptional

Gleno — Sat, 14 Mar 2026 07:19:12 +0000

Why this matters
1. Keep scope brutally clear
2. Give your model a stronger quality bar
3. Make it critique itself before and after
4. Separate build passes from polish passes
5. Make it work against a reference standard
The playbook
The biggest unlock
My strongest recommendation

Why this matters

I'm interested to hear how other vibe-coders are getting the best out of whatever model they are using. For me, and Claude, I've been reading everything, everywhere in order to improve my already pretty great outcomes and make more robust software and applications.

I’ve found that the difference between average AI-assisted coding and genuinely impressive output often has less to do with the model itself and more to do with how you direct it. In other words, the biggest improvement usually comes from becoming a better editor, product owner, and critic of the work.

This article is basically my current thinking on how to get better results. Not just more code, but better code. Better UX. Better structure. Better judgment. Less fluff. Less fake completeness. Less "looks great in a screenshot, falls over in real life."

1. Keep scope brutally clear

The first big improvement for me was realising that the model does best when the task is:

narrow
concrete
sequenced
judged against a clear standard

What hurts quality is asking for too much at once:

coding
product decisions
architecture
UX redesign
future planning

all bundled into one giant prompt.

The best pattern I’ve found is:

one task
one success definition
one summary at the end

Good prompt:

Improve the dashboard filter UX only. Do not add scope. Focus on clarity, spacing, active filter visibility, and reducing clicks. After changes, summarize what improved and what tradeoffs remain.

Less good prompt:

Make the whole app more modern, smarter, and production-ready.

That second prompt sounds ambitious, but it usually produces mush. The model starts solving five different problems badly instead of one problem well.

2. Give your model a stronger quality bar

Another thing that helped me a lot was stopping myself from only telling the model what to do and instead telling it what good looks like.

Don’t settle for technically correct if what you actually want is product-quality work.

Quality bar prompt:

Aim for senior product-quality work, not just technically correct implementation.

Bar for quality:

obvious, calm, low-friction UX
strong visual hierarchy
consistent naming and spacing
no unnecessary complexity
no fake completeness
preserve user familiarity where helpful
improve common workflows, not edge-case cleverness

For UI work, I’ve also found it helps to be even more direct:

UI quality prompt:

Do not settle for generic dashboard SaaS. Make this feel immediately understandable to experienced users, but cleaner, calmer, and easier to scan.

That little shift makes a big difference. Otherwise the model often gives you something that is fine in a technical sense but generic in every other sense.

3. Make it critique itself before and after

This is one of the best tricks I’ve found.

Before it changes anything, get it to identify weak spots. After it changes things, get it to critique the result honestly.

That helps push it out of “task completed” mode and into “quality review” mode.

Before coding:

Before coding, identify:

the 3 weakest parts of the current implementation for this task
the biggest risk of making it worse
the standard you will use to judge success

After coding:

After coding, critique your own work:

what improved materially
what still feels weak or generic
what a strong human product designer would probably still want changed

That has been incredibly useful for me because the model will often otherwise sound pleased with itself far too early.

4. Separate build passes from polish passes

One thing I’ve had to learn is not to expect the first pass to also be the best pass.

The model can build quickly, but quality usually comes from doing the work in layers.

My preferred sequence is:

build it
verify it
refine UX
clean code
document next gaps

That feels much closer to how good teams actually work.

Refinement pass prompt:

Do not add features.

Now do a refinement pass on the existing implementation only.

Improve:

spacing
hierarchy
wording
empty states
action discoverability
friction in common interactions

Do not redesign the product. Tighten what already exists.

That distinction between build pass and polish pass has improved my results a lot.

5. Make it work against a reference standard

The model does better when it has something to aim at.

If you already know the kind of experience you want, say so clearly and repeatedly. Don’t assume the model will infer your taste.

For me, this often means defining a few non-negotiables around familiarity, clarity, calmness, cognitive load, and usability.

Design standard prompt:

Design standard:

preserve familiar mental models where helpful
reduce clutter
make active state obvious
improve scanability
reduce clicks
make common actions easier to find
use calmer, cleaner visual hierarchy

Prefer familiarity for core workflows and innovation only where it clearly improves speed, confidence, or clarity.

This helps stop the model wandering off into novelty for novelty’s sake.

The playbook

Here’s the practical version of how I now try to work.

Review every summary properly

When the model says it has completed something, I ask myself:

Did it solve the real user problem?
Did it stay in scope?
Did it introduce unnecessary complexity?
Does it feel generic?
Would a busy user understand this quickly?
Does it still feel like the kind of product I’m trying to make?

If the answer is “technically yes, emotionally meh,” that usually means it needs a refinement pass.

Ask for rationale on UI tasks

Not chain of thought. Just design rationale.

UI rationale prompt:

For each significant UI change, explain:

what stayed familiar
what improved
why it reduces cognitive load
any tradeoff between clarity and familiarity

That helps surface whether the model is making deliberate choices or just decorating things.

Keep a quality debt list

This has been useful too.

I like having the model maintain a small file of things that are still weak, awkward, or unfinished, such as:

awkward labels
generic empty states
spacing that still feels off
interactions that are too hidden
things that need real user testing

Quality debt prompt:

Maintain a short docs/quality-debt.md with only meaningful remaining UX/code quality issues. Keep it concise and prioritized.

That stops “good enough” from becoming invisible.

Make it do a cleanup pass

Before a task is truly finished, I often want one more sweep for consistency and simplification.

Cleanup pass prompt:

Before you finish this task, do a cleanup pass for:

naming consistency
dead code
duplicate logic
awkward wording
spacing inconsistencies
unnecessary abstractions

Force human-grade restraint

This one matters more than people think.

The model loves adding layers, helpers, hooks, abstractions, and future-proofing when they are not actually needed.

Restraint prompt:

Do not add abstractions, helper layers, hooks, or configuration unless they clearly reduce present complexity. Prefer simple, readable code over future-proofing theater.

That line alone can save a surprising amount of nonsense.

For UI/UX specifically

If I want the best UI/UX possible, I try to push the model toward these principles:

10-second scanability
recognition over recall
fewer competing focal points
obvious primary actions
visible active state
trustworthy summary-to-detail flows
calm density, not empty Dribbble fluff
tables and controls that are genuinely usable

Click to see the full UI polish prompt
Do not add scope.

Refine the current UI to improve:

scanability in under 10 seconds
visual hierarchy
spacing consistency
filter clarity
table readability
action discoverability
trust and calmness of the interface

Keep the core mental model familiar.
Do not turn this into a flashy SaaS dashboard.
Explain what changed, why it is better, and what still feels weak.

That prompt has been a good one for me because it pushes the model toward clarity instead of visual showing off.

The biggest unlock

One of the best prompts I’ve used is asking the model what a great human would still dislike about the work.

Critique from multiple perspectives:

Critique this implementation from the perspective of:

a strong senior engineer
a strong product designer
a skeptical internal business user

What would each still dislike or question?
Then improve the top issues that are in scope.

That often gets you a better result than simply saying “make it better.”

My role in all this

The way I think about my job now is this:

My role is to stop the model becoming:

too broad
too clever
too generic
too pleased with itself

and keep pushing it toward being:

clearer
tighter
calmer
more honest
more product-quality

That has made a massive difference.

My strongest recommendation

If I had to pick one thing that consistently improves output, it would be adding an excellence pass after each meaningful chunk of work.

The excellence pass prompt:

Do not add scope.

Now do an excellence pass on the existing implementation.

Raise the quality of the work without changing the product scope.

Focus on:

code clarity
naming consistency
removal of dead or unnecessary complexity
UI hierarchy
spacing and readability
action discoverability
empty/loading states
reduction of cognitive load

Then critique the result honestly:

what is now strong
what still feels average
what still needs human judgment

That has probably been the single best quality multiplier for me.

Final thought

I’d genuinely love to hear how other people are getting the best out of their models.

What are you doing that consistently improves outcomes?

Are you using:

tighter prompting
staged passes
self-critique
design standards
test-first workflows
something else entirely?

Because the more I do this, the more I think the real skill in vibe-coding is not just getting the model to produce code.

It’s getting it to produce work you’d actually be proud to ship.

I reviewed a lot of chatter about AI-assisted engineering (vibe-coding) and it's a little scary TBH

Gleno — Fri, 13 Mar 2026 18:42:57 +0000

AI-assisted engineering, SaaS anxiety, and the new mood in software

Gleno ・ Mar 13

#discuss #ai #saas #news

AI-assisted engineering, SaaS anxiety, and the new mood in software #Episode 1

Gleno — Fri, 13 Mar 2026 18:41:08 +0000

Everyone is asking some version of the same question now: if AI makes software dramatically easier to build, what happens to software businesses?

The strongest mood I’m seeing is not “SaaS is dead,” but something more unsettling: the cost of building software is falling fast, which means weak software moats are getting exposed. The moat is shifting away from raw implementation and toward distribution, trust, proprietary data, deep workflow ownership, compliance, and operational excellence.

That is the backdrop to a lot of the sharpest opinion pieces being written right now.

My take
Articles and blogs
Themes showing up across the debate
Final thoughts

My take

Here is the broad feeling in the software world right now: excitement on the surface, anxiety underneath.

There is genuine optimism that AI-assisted engineering (vibe coding) can make small teams absurdly productive. It is easier than ever to prototype, ship, test ideas, and build useful internal or niche software without a giant engineering org. That part is real, and a lot of writers are no longer treating it as a novelty.

But there is also a growing suspicion that the old software business playbook is weakening. If code generation becomes cheaper, faster, and more accessible, then software companies can no longer lean so heavily on “it took years to build” as their main justification for valuation, pricing, or defensibility.

So the current vibe is not quite doom, and not quite triumph. It is more like this:

Software is getting easier to create, harder to defend, and more important than ever to operate well.

That is why the conversation has become so charged. People are not really arguing about code editors. They are arguing about whether the economics of software are changing under everyone’s feet.

Articles and blogs

Good news: AI Will Eat Application Software

One of the boldest takes in the whole debate. The argument is that application software is becoming less defensible as AI lowers the cost of reproducing product functionality, and that users increasingly care more about outcomes than about seat-based tools. This is a strong inclusion if you want a fearless, investor-style view of the pressure building under traditional SaaS.

From Demos to Deals: Insights for Building in Enterprise AI

A useful piece on how AI companies may need to operate differently from classic SaaS companies. The emphasis is not just on building the product, but on how product commoditization changes go-to-market, value capture, and what an enduring moat might actually look like in AI.

The New Rhythm of the Enterprise Sale

This one is less about coding and more about business mechanics. The key idea is that AI is changing not only what companies buy, but how quickly they evaluate and replace software. That matters because shorter replacement cycles are bad news for sleepy incumbents.

Whether AI is a bubble or revolution, how does software survive?

A thoughtful middle-ground essay. The framing here is that cheap software generation does not mean all software value goes to zero; it means the economics of smaller, simpler tools are changing much faster than the economics of high-stakes systems. Good for readers who want nuance instead of chest-beating.

Why demand for code is infinite: How AI creates more developer jobs

A useful counterweight to the “software jobs are over” narrative. The argument is that lowering the cost of creating software can increase the total amount of software the world wants, which may expand demand even while changing what developers actually do.

A new worst coder has entered the chat: vibe coding without code knowledge

This captures the backlash side of the conversation. The point is not that AI-assisted engineering is fake, but that it can make it much easier to generate impressive-looking nonsense and push brittle software further than it deserves to go.

Not all AI-assisted programming is vibe coding

One of the most useful framing pieces on the whole subject. Simon Willison separates carefree, high-trust prompting from more accountable AI-assisted programming. It is a good reminder that not all AI-heavy coding practices are equally reckless.

Will the future of software development run on vibes?

A short but sharp warning. The basic message is that AI-first development is fantastic for experiments and prototypes, but dangerous when people let a “good enough” prototype slide into production without the engineering discipline that production systems require.

AI-assisted coding for teams that can't get away with vibes

This is a good bridge piece between fast AI experimentation and serious delivery. It speaks directly to teams that still need maintainability, accountability, and reliability, even while using AI heavily.

My LLM coding workflow going into 2026

A practical and disciplined view of how experienced engineers are folding AI into real work. Rather than treating AI as magic, it presents a workflow where AI speeds things up but the human still owns the outcome.

The reality of AI-Assisted software engineering productivity

A useful reality check. The argument is that AI can absolutely save time, but coding is only one part of software delivery, so the gains are often uneven. It is a good antidote to simplistic “10x developer” claims.

How to write a good spec for AI agents

This piece is really about where the world may be heading next: from prompting by instinct to building with clearer specs and more structured intent. It hints at a future where software teams become more like editors, orchestrators, and reviewers of machine-generated work.

Themes showing up across the debate

1. The moat is moving, not disappearing

The strongest recurring idea is that code itself is becoming less scarce, but software advantage is not vanishing — it is relocating. The defensibility is moving toward distribution, trust, data, integration depth, workflow ownership, and the ability to operate reliably at scale.

2. Weak SaaS looks shakier than strong SaaS

The software businesses under the most pressure seem to be the ones selling generic, shallow, seat-based tools with limited differentiation. If your product can be approximated quickly by a smart team using AI, the market is going to ask hard questions.

3. “Can build” and “can run” are diverging

This is one of the most important distinctions in the current discussion. AI makes it easier to build software. Running resilient, secure, supportable systems is still a different discipline. The gap between those two things is becoming more visible.

4. The winners may look more like operators than coders

A lot of the opinion pieces point to the same conclusion: the next winners may not be the teams writing the most code, but the teams that understand the workflow best, own the customer relationship, integrate deeply, and use AI to move faster without losing control.

Final thoughts

The overall vibe in the software world right now is restless, opportunistic, and slightly paranoid.

There is a sense that something big has already shifted, even if nobody agrees yet on where it ends. The loud optimists think AI-assisted engineering will blow up the old SaaS model and turn software into a faster, cheaper, more fluid business. The more grounded voices think that is only half true: software creation is being commoditized, but software operations, trust, and workflow ownership are becoming even more valuable.

That feels closest to reality.

So no, SaaS does not look dead soon. But it does look less comfortable. Less protected. Less able to rely on historical effort as proof of future value.

The old story was: building software is hard, so incumbents are safe.

The new story seems to be: building software is getting easier, so incumbents have to prove they deserve to survive.

And that is the mood now more than anything else.

Claude's take on the Slawk Codebase (14-day build)

Gleno — Thu, 12 Mar 2026 23:07:13 +0000

Engineering Review

Overall Assessment: B+

This is a strong result for a 14-day build.

It shows real engineering judgment in the places that matter: security awareness, validation discipline, transactional correctness, and test coverage. It does not read like a fragile demo or a pure UI clone. It reads like a serious prototype built by someone who understands backend risk and has made a genuine effort to control it.

The codebase is not production-ready yet, but the gap is mostly operational maturity rather than fundamental incompetence or weak foundations.

What is strong

1. Security posture is materially better than average for a fast build

There are several decisions here that indicate actual security thinking rather than cosmetic hardening:

timing attack mitigation
token revocation through tokenVersion
per-user WebSocket rate limiting
UUID-based filenames
bcrypt with cost factor 10

That is a better baseline than many production systems shipped under normal timelines.

2. Input validation is consistently applied

Validation appears to be taken seriously across the API surface:

Zod is used across most endpoints
null byte filtering is present
channel naming includes path traversal prevention

That consistency matters. A lot of rushed applications have one or two “secure” endpoints and then obvious gaps elsewhere. This does not appear to be one of those cases.

3. Transaction boundaries are correctly used

Prisma transactions are being used in the right places, especially around message creation and counter updates. That suggests a correct understanding of atomicity and reduces the likelihood of subtle race-condition bugs in core workflows.

4. Architecture is clean and understandable

The separation between Express routes, middleware, Prisma access, Socket.io handling, and Zustand stores is sensible. The code appears structured for maintainability rather than just speed of initial assembly.

5. Test coverage is meaningful

Sixty-eight backend tests, including multi-user and security-oriented scenarios, is a strong showing for a project of this age. More importantly, the tests are exercising the right categories of risk rather than just happy-path CRUD.

Real issues

High severity

In-memory rate limiting and account lockout
This is the one serious production blocker.

Both controls are stateful security mechanisms, and in-memory implementations fail in exactly the situations where they matter most:

process restart clears enforcement state
horizontal scaling causes inconsistent enforcement across instances
failover behavior becomes unpredictable

For a real deployment, this needs to move to Redis or to durable database-backed counters with clear expiry semantics.

Medium severity

Duplicated message creation logic across REST and WebSocket handlers
This is not immediately dangerous, but it is a maintainability and consistency risk. Message creation rules should live in a shared service layer or domain function so validation, side effects, and persistence semantics stay aligned across transports.

Weak HTML stripping approach
Using a regex such as /<[^>]*>/g is not a reliable sanitization strategy and can be bypassed. If rich text or user-supplied markup is in scope, sanitization should be handled by a proper HTML sanitizer with an explicit allowlist strategy. If markup is not needed, escaping on output is safer than attempting ad hoc stripping.

No audit logging for sensitive administrative operations
Role changes, user deactivation, and similar privileged actions should produce durable audit records. Without that, incident review, internal accountability, and enterprise-readiness are all weaker than they should be.

Overly broad WebSocket CSP policy
Allowing all wss: origins is unnecessarily permissive. This should be constrained to same-origin or to a strict allowlist of expected WebSocket endpoints.

Low severity

No frontend error boundaries
A render failure taking down the whole app is not unusual in an early build, but it should be corrected before broader usage. Error boundaries around the main application shell and higher-risk UI surfaces would materially improve resilience.

Ephemeral JWT secret fallback in development
This is mostly a developer-experience issue rather than a production risk, assuming production secrets are properly configured. Still, random secret fallback causes token invalidation on restart and can obscure auth-related debugging.

Verdict

For a 14-day experiment, this is impressive work.

The most notable thing is that the author spent effort in the right places. The foundations are not superficial. Security, validation, transaction safety, and tests all indicate competent engineering judgment.

The main deficiency is operational readiness. The current design still assumes a single-process, non-distributed execution model for some important control paths. That is acceptable for a prototype, but it is the first thing that breaks when the system is exposed to real production conditions.

Non-negotiable production fix

Before this should be considered for production use with real users:

Replace in-memory rate limiting and account lockout with Redis or an equivalent durable shared store.

That is the only issue here I would classify as a true release blocker.

Everything else is real, but secondary:

reduce duplication in message creation paths
replace regex-based HTML stripping with proper sanitization or output escaping
add audit logging for privileged actions
tighten WebSocket CSP
add frontend error boundaries

Final view

This is better than most 14-day builds, and frankly better than plenty of software that is already in production.

The right summary is not “finished,” and it is not “just a demo” either.

It is a credible early-stage system with solid engineering instincts and one clear operational maturity gap that must be addressed before production.

Building a Real Product With AI: Progress on the “AI Dev Team of One”

Gleno — Tue, 10 Mar 2026 06:55:21 +0000

Firstly, excuse the AI generated image. This is the Lone Ranger on a robot horse apparently..

Anyhoo, a few days ago I wrote about the idea of the AI developer team of one — the notion that a single developer, working with modern AI coding tools, can operate more like a small engineering team than an individual contributor.

At the time that post was mostly theoretical. I had only just started building something to test the idea.

Since then I’ve been running the experiment properly.

The project I’ve been building is a small application designed to answer a surprisingly common business question:

“Will this invoice actually be accepted by the company I'm sending it to?”

It turns out that this question is more complicated than it sounds.

Different organisations have very specific requirements for invoices. Some require purchase orders in strict formats. Others require exact site names. Some ingest invoices via OCR, others via EDI or Peppol networks. When those rules aren't followed, invoices get rejected or delayed.

So the system I'm building tries to check invoices before they are sent and predict whether the buyer's systems will accept them.

The interesting part, though, isn't just the software itself.

It's how it was built.

The development experiment

Instead of building the application entirely by hand, I used AI coding tools as collaborators.

In practice my workflow looks something like this:

Claude Code handles most implementation work
ChatGPT helps with architecture, design thinking, documentation, and code review
GitHub tests and type checking act as guardrails

Rather than typing every line of code myself, the process feels more like directing a small engineering team.

I describe the architecture or change I want.

The AI proposes an implementation plan.

I review it, adjust the direction if needed, and then let it execute.

The result feels surprisingly similar to working with a junior or mid-level developer: the AI does the bulk of the typing, while I focus on the structure of the system.

What the system does now

The application converts invoices into a canonical internal format, which allows invoices from different accounting systems to be processed consistently.

Once the invoice is in that format, the system runs several layers of analysis.

First it validates the structure of the invoice to ensure the data is coherent. Then it applies buyer-specific rules — things like purchase order formatting or required fields.

After that it calculates a readiness score, which indicates how close the invoice is to meeting the buyer's requirements.

For example:

Invoice readiness: 82%

Errors: 1

Warnings: 2

Issues detected:

Purchase order must be 10 digits
Site name must match official buyer list

The goal is not just to say “valid” or “invalid,” but to give clear guidance on what needs fixing before the invoice is sent.

The system also runs a buyer acceptance simulation, which predicts whether the buyer's system is likely to accept the invoice automatically.

That step turns the tool from a simple validator into something closer to a buyer compliance engine.

Guardrails matter more than prompts

One of the biggest lessons from this experiment is that good guardrails matter more than clever prompts.

It’s tempting to think that the secret to AI-assisted development is prompt engineering.

In reality, the most important factor has been putting constraints around the system.

Those guardrails include:

strong TypeScript typing
automated tests
deterministic validation rules
versioned invoice models
audit logging

These systems allow the AI to make large code changes safely.

If something breaks, the tests catch it immediately.

Without those guardrails, the system would drift quickly.

With them, the AI can move very quickly without losing control of the codebase.

How much time did this actually take?

One of the most interesting questions people have asked is how much time this project required.

So far, I’ve spent roughly 8–12 hours of my own time working on the project across a few sessions.

That includes:

architecture thinking
reviewing AI implementation plans
adjusting prompts
checking test results
writing documentation

The actual code produced during that time is significantly larger than what I would normally write in that time window.

How long would a traditional team take?

This is obviously a rough comparison, but it’s useful to think about.

To reach the current stage — which includes:

canonical invoice modelling
validation engine
buyer rule system
readiness scoring
acceptance simulation
artifact generation (Peppol XML, CSV, etc.)
API endpoints
automated tests
documentation

A traditional development process might involve:

a product owner
a backend developer
a frontend developer
possibly a QA engineer

Even with a small team moving quickly, that work could easily represent 120–200 hours of engineering time.

Spread across a typical development cycle, that would likely mean three to six weeks of work before reaching the same level of functionality.

That difference doesn’t mean AI replaces developers.

But it does change the economics of experimentation.

Ideas that previously required weeks of engineering effort can now reach a working prototype in a matter of hours.

The most interesting direction the project is heading

The original goal was simply to validate invoices.

But something more interesting started to emerge while building the system.

As buyer rules are added — for example, Mitre 10 requirements, government invoicing rules, or Peppol constraints — the system starts to accumulate knowledge about how different buyers operate.

Over time this could become a shared registry of buyer requirements:

purchase order formats
accepted invoice structures
known rejection patterns
integration formats

At that point the product stops being just an invoice validator.

It becomes a buyer compliance knowledge system.

What this experiment changed for me

The biggest change isn’t just productivity.

It’s how development feels.

Instead of spending most of the time typing code, a lot of the work becomes:

designing the architecture
defining constraints
reviewing implementation plans
steering the system toward the correct design

The role becomes closer to directing an engineering team than acting as a single developer.

And surprisingly, that workflow works.

What happens next

At this point the focus shifts from building features to something more important:

showing the system to real users.

Because ultimately software isn’t valuable because of how it’s built.

It’s valuable if it solves a real problem.

In this case, the question is simple:

Can a system like this help businesses avoid invoice rejections and get paid faster?

That’s my next experiment.

The Missing Guardrail in AI Coding: Protecting Architecture

Gleno — Tue, 10 Mar 2026 00:43:58 +0000

Most discussions about AI-assisted development focus on prompting.

Better prompts.
Better instructions.
Better discipline when asking the AI to write code.

And while that absolutely helps, I think prompting discipline is only the first layer of guardrails.

The deeper guardrails are the ones that live in the system itself.

In the last few weeks I've been experimenting with a workflow where AI writes and modifies code inside a repository that constantly checks whether those changes are acceptable. The AI can propose changes freely, but the system pushes back if something drifts too far.

The interesting thing is that these guardrails are not particularly exotic. They are mostly the same tools developers have been using for years.

Type checking.

Tests.

Linting.

Structured workflows.

But once AI enters the loop, those tools become much more important.

The Real Risk Isn't Bad Code

The biggest problem I see with AI-generated code is not that it produces obviously broken programs.

The bigger problem is something subtler.

AI often produces changes that are individually reasonable but collectively incoherent.

A function gets renamed here.

A data structure gets reshaped there.

A validation rule moves to a different layer.

Each change looks fine in isolation. But over time the system slowly drifts away from its original architecture.

Eventually the code still compiles and even passes some tests, but the structure that made the system understandable has been eroded.

I think of this as the plausible but incoherent problem.

Guardrails That Actually Work

The most effective guardrails I've found so far are the ones that run automatically after every change.

For example:

TypeScript type checking immediately catches structural mistakes.

Unit tests verify that the core logic still works.

End-to-end tests ensure the user workflows are still intact.

These are not new ideas, but they become far more valuable once AI is writing large portions of the codebase.

Instead of relying on the developer to remember rules, the system itself becomes the enforcer.

The Missing Guardrail: Architecture Protection

There is another guardrail that I think teams will start adopting soon.

Protecting the architecture itself.

Traditional tests verify behaviour. They ask questions like:

Does this function return the right result?

Does this API endpoint respond correctly?

But architecture tests ask a different question:

Did the structure of the system remain the same?

For example, in the system I'm currently building, everything revolves around a canonical invoice data structure. If that structure drifts, the entire pipeline breaks.

So one approach I'm exploring is golden output tests.

Given a known invoice input, the system must always produce the same validated output structure.

If AI-generated changes alter that structure unexpectedly, the tests fail immediately.

This protects the boundaries between layers of the system, not just the behaviour of individual functions.

AI Inside Guardrails

What I'm gradually discovering is that AI works best when it operates inside a constrained system.

The workflow ends up looking something like this:

The AI proposes changes.

The repository runs automated checks.

Failures are reported back.

The AI adjusts the implementation.

Instead of treating prompting as the only control mechanism, the repository itself becomes a feedback loop.

The AI can explore solutions, but the guardrails prevent it from drifting too far from the intended design.

The Future: Policy-As-Code for Architecture

This idea is not entirely new.

Infrastructure teams have been moving toward policy-as-code for years. Security rules, deployment constraints, and compliance requirements are expressed as machine-checkable rules.

I suspect application architecture will move in a similar direction.

Instead of relying purely on documentation and conventions, systems will increasingly encode architectural constraints directly into tests and automated checks.

AI will still generate code.

But it will do so inside an environment that continuously evaluates whether those changes respect the architecture.

That feels like a much more sustainable model than relying on perfect prompting.

And if AI-assisted development keeps accelerating, I suspect these kinds of architectural guardrails will become essential.

AI Might Create a New Job: The Developer Inside Every Business

Gleno — Mon, 09 Mar 2026 08:47:06 +0000

For the past two years we've been asking the wrong question about AI and software development.

The question everyone keeps asking is:

Will AI replace developers?

But after spending time building software with AI coding tools, I’ve started to suspect something very different might happen.

AI might not eliminate developers.

It might create demand for more of them — just in places that never hired developers before.

In particular, it may create a new role that many companies have never had:

the internal developer.

The Company With No IT Department

Imagine a typical mid-sized business.

Maybe 30–60 employees.

They are good at what they do, but their internal systems look familiar to anyone who has worked outside the tech industry.

Spreadsheets everywhere.

Quotes built in Word.

Customer notes stored in email threads.

Information scattered across accounting software, shared drives, and manual processes.

None of it is completely broken. But none of it is particularly efficient either.

Historically these businesses solved software problems in three ways:

• buy SaaS products

• hire consultants

• live with inefficient processes

Custom software was rarely an option.

Not because the problems weren’t worth solving.

But because building software felt expensive, risky, and slow.

How Software Has Traditionally Been Built

For most companies, the model looked something like this:

This approach works, but it creates friction.

Projects take time. Requirements must be carefully written. The people building the system are often external to the business itself.

As a result, many operational problems simply never get solved with software.

They remain spreadsheets.

AI Changes the Starting Point

AI-assisted development tools change one critical thing:

They dramatically lower the cost of creating the first version of a system.

Now imagine someone inside that business starts experimenting with AI coding tools.

Within a few days they produce a rough internal tool:

• a quoting calculator

• a small workflow form

• a dashboard showing job status

It isn’t perfect.

But it works.

And suddenly the company realises something important.

Custom software might no longer be unreachable.

A Different Model Starts to Appear

Instead of software always being built outside the business, the workflow might start to look like this:

The company no longer needs to start with a consultancy engagement.

They can start with experimentation.

That’s a very different starting point.

The First Internal Tool

Imagine the first real success.

Someone builds a small quoting system.

The impact is immediate:

• quotes are generated faster

• pricing becomes consistent

• information is stored properly

• reporting becomes possible

The tool might only save a few hours each week.

But the business now sees something it has rarely experienced before:

A problem solved exactly the way their workflow needs it solved.

That’s when the mindset changes.

Instead of asking:

“Which software should we buy?”

The company begins asking:

“Could we build something for this?”

The Hidden Reality

Once that first internal system exists, a new reality appears.

Software isn’t just something you build.

It’s something you own.

The system needs improvements.

Someone reports a bug.

Another team wants a similar tool.

AI may make building software easier, but it does not remove the need for someone who understands how the system works.

That responsibility has to live somewhere.

The Internal Developer

At this point a new role quietly emerges.

Not a full engineering team.

Not necessarily even a traditional software engineer.

But someone inside the business who becomes responsible for the company’s internal software capability.

Someone who can:

• understand business workflows

• design simple systems

• use AI tools to build and evolve them

• maintain those systems over time

This person becomes the bridge between how the business operates and the software that supports it.

Historically many companies never needed that role.

AI might change that.

A New Kind of Demand

For decades, most companies outside the tech industry simply didn’t hire developers.

They relied on vendors, consultants, and packaged software.

But if AI makes building internal tools dramatically cheaper, the economics change.

Instead of outsourcing every project, many companies may decide it makes sense to have one internal builder who understands their systems and can create solutions when needed.

Across thousands of companies, that could represent a significant shift.

Not fewer developers.

Just developers working in different places.

The Real Opportunity

The interesting implication is not that AI replaces developers.

It’s that AI might make software creation accessible to businesses that previously couldn’t justify it.

That means:

• more internal tools

• more automation

• more operational software solving real problems

In other words:

more software built in more places.

Places that previously had none.

A Question I'm Curious About

If AI continues lowering the barrier to building software, do you think we'll start seeing more companies hire one internal developer instead of relying entirely on agencies?

Or will consultancies simply adopt AI themselves and keep the existing model?

I'm curious what other developers are seeing in the real world.

The Prompt Pattern That Made AI Coding Actually Work

Gleno — Mon, 09 Mar 2026 05:05:12 +0000

When I first started experimenting seriously with AI-assisted development, I ran into the same problem many people seem to hit.

The AI could write code.

But the results were inconsistent.

Sometimes the output was excellent. Other times it was strange, overly complicated, or subtly wrong. Even when the code worked, it sometimes didn’t quite fit the system it was supposed to belong to.

At first I thought this was just the nature of the tools.

But after a few weeks of experimenting I realised the real issue wasn’t the AI.

It was the way I was asking it to work.

The biggest mistake I was making was simple: I was asking the AI to start coding immediately.

Once I changed that, everything improved.

The problem with "just build this"

Early on my prompts looked something like this:

Build an API endpoint for validating invoices.

Or:

Refactor this validation function.

Or:

Add support for buyer-specific rules.

The AI would respond quickly and confidently. Files would appear, functions would change, and new structures would sometimes emerge that looked quite reasonable.

But there was a subtle issue.

The AI was making architectural decisions on my behalf.

Sometimes those decisions were fine. Other times they introduced inconsistencies or patterns that didn’t quite match the rest of the system.

The problem wasn’t that the AI was bad at coding.

The problem was that it was improvising.

The pattern that changed everything

Eventually I started using a much stricter prompt pattern.

Instead of asking the AI to implement something directly, I ask it to go through a small planning process first.

The pattern looks like this:

Scan the repository
Explain the relevant architecture
Propose a minimal implementation plan
Wait for approval
Then implement the change

The difference this makes is surprisingly large.

When the AI explains the architecture first, it usually discovers existing structures that should be reused. When it proposes a plan, it often reveals assumptions that can be corrected before any code is written.

By the time implementation begins, the AI is no longer guessing.

It is executing a plan.

Why this works

There’s a simple reason this pattern is effective.

AI models are very good at generating code, but they don’t naturally pause to reason about the system unless you explicitly ask them to.

If you jump straight to implementation, the model fills in the missing context however it thinks is best.

That can work sometimes.

But if the system has any real complexity, it’s much safer to force the AI to describe the system first.

This accomplishes two things.

First, it gives the AI a chance to understand the existing architecture before making changes.

Second, it gives the human developer a chance to review the plan and catch mistakes before they turn into code.

What this looks like in practice

When I’m working on my current project, the prompt often looks something like this:

Scan the repository and explain how invoice validation currently works.

Then propose the smallest safe implementation plan for adding buyer-specific rules.

List the files that would need to change, and wait for approval before implementing anything.

The response usually includes a clear explanation of the existing system along with a step-by-step implementation plan.

Only after reviewing and approving that plan do I ask the AI to proceed.

At that point, implementation becomes very fast.

The role of the developer changes here

This workflow also changes how the developer interacts with the AI.

Instead of acting like someone requesting code, the developer starts acting more like someone directing an engineering process.

The AI proposes plans.

The developer approves or modifies them.

Then the AI implements the result.

In other words, the human remains responsible for the architecture, while the AI accelerates the implementation.

That separation turns out to be extremely important.

The surprising result

Once I started using this pattern consistently, the quality of the AI’s output improved dramatically.

The code fit the existing system better. Changes were smaller and more targeted. The AI was less likely to invent unnecessary abstractions or refactor unrelated parts of the repository.

The tools didn’t change.

The prompt did.

And that turned out to make all the difference.

A simple rule

If you’re experimenting with AI coding tools, one small change can improve your results immediately.

Don’t start with implementation.

Start with understanding.

Ask the AI to explain the system first, propose a plan second, and implement only after the plan is clear.

It slows the process down by a few minutes.

But it saves a lot of confusion later.

What I’ve Been Building With AI (ChatGPT + Claude)

Gleno — Mon, 09 Mar 2026 04:00:12 +0000

Hi everyone — I'm Glen.

I live and work in New Zealand and spend most of my time building software. My day job is as a FileMaker developer, but lately I’ve been spending a lot of my spare time experimenting with AI-assisted development and seeing how far a single developer can push things with the current generation of tools.

I've been in IT for quite a while (though relatively new to the FileMaker ecosystem), and the speed at which AI tools can help you move from idea to working system is pretty remarkable.

Over the last few weeks I decided to test something properly.

Instead of just experimenting with prompts or small scripts, I started building a real system to see what AI-first development actually looks like in practice.

The project is called InvoiceReady.

What I'm building

The goal of InvoiceReady is fairly straightforward: help companies validate invoices before sending them into networks like Peppol, where invoices often get rejected because of formatting issues, missing fields, or buyer-specific rules.

If you've worked with systems like Peppol you’ll know that the hardest part isn’t generating the invoice — it’s making sure the invoice satisfies all the rules before it gets sent.

So the platform focuses on catching those issues early.

Right now the system includes:

a canonical invoice data model
a multi-layer validation engine
buyer rule management
destination profile configuration
invoice versioning and history
a sandbox testing environment
an external API designed for integration with systems like FileMaker

The validation engine works in layers.

System checks
Peppol baseline rules
Buyer-specific requirements
Destination rules

Each layer validates the invoice data before it ever gets sent to a network.

The idea is simple: catch problems before an invoice ever leaves your system.

The development setup

The interesting part isn’t just the project itself, but how it’s being built.

Instead of a traditional workflow, I’ve been using a combination of:

ChatGPT for architectural thinking, planning, and writing
Claude Code for repository implementation
Next.js + TypeScript for the application
Supabase for the database

For anyone curious about the tooling: I'm not using the free tiers.

I'm currently on the paid plans just above the free tier for both ChatGPT and Claude.

That gives enough usage to work with them continuously while building real software, without constantly hitting limits. Even combined, the monthly cost is still fairly modest compared to traditional development tooling.

How the workflow actually works

The most important thing I've learned so far is that AI development only works well if you control the workflow.

The loop I'm using looks something like this:

Think through the architecture
Define a clear implementation plan
Ask Claude to implement the change in the repository
Run type checks and tests
Iterate

In other words, the AI isn't just asked to "build something".

It is asked to implement a plan.

The rule I've been following is simple:

Never let the AI start coding without a plan.

Once the plan is clear, the implementation phase becomes dramatically faster.

Tasks like scaffolding routes, wiring APIs, generating types, creating migrations, and even producing tests can happen in minutes.

The bottleneck stops being implementation.

The bottleneck becomes decision quality.

What surprised me

The biggest surprise wasn’t that AI can generate code.

It was how quickly the implementation layer stops being the constraint.

Once the architecture is clear, the AI can produce large amounts of surrounding implementation very quickly.

What ends up taking the most time is deciding:

what the system should actually do
where the logic should live
what the smallest safe change is
what shouldn't be built at all

Those are architectural questions.

AI can help with them, but they still require human judgment.

What still requires human oversight

AI is very good at producing code that looks plausible.

But plausible code isn’t the same as a coherent system.

The areas that still require the most careful attention are things like:

system architecture
domain modelling
product decisions
defining boundaries between components
deciding when something is the wrong feature entirely

In other words, the AI can accelerate implementation, but it doesn’t replace the thinking that keeps a system stable.

If anything, those decisions become more important because implementation is now so fast.

Why I'm writing about this

There’s a lot of hype around AI coding tools right now.

Some of it is deserved.

But the real shift isn't simply that AI can write code.

The real shift is that a single developer can now coordinate something that behaves more like a small engineering team — if the workflow is structured properly.

That’s what I’m experimenting with.

Building a real system.

Using AI as the primary implementation layer.

And documenting what works, what breaks, and what turns into chaos if you're not careful.

I'll keep sharing what I learn as the project evolves.

The AI Development Loop

Gleno — Mon, 09 Mar 2026 03:54:42 +0000

A lot of discussion around AI-assisted development focuses on tools.

Which model should you use?

Which coding assistant is best?

Which IDE plugin works the fastest?

Those questions are interesting, but they miss something more important.

AI-assisted development is not really about tools.

It is about workflow.

When people struggle with AI coding tools, it is usually not because the model is bad. It is because the workflow is wrong. They ask the AI to produce code immediately, without context, planning, or structure.

That works occasionally for small tasks.

But for real systems, it quickly creates confusion.

What actually works is a loop.

A repeatable cycle that separates thinking from implementation and keeps the human in control of the system.

I think of it as the AI development loop.

The basic structure

The loop is simple.

An idea appears.

The architecture is examined.

A plan is created.

AI implements the plan.

The result is tested.

Then the system evolves again.

Visually it looks something like this:

Idea

↓

Architecture Review

↓

Implementation Plan

↓

AI Implementation

↓

Testing

↓

Iteration

The important detail is not the diagram itself.

The important detail is the order.

Thinking happens before implementation.

Why this loop matters

In traditional development, the implementation phase was expensive. Writing code took time, and that time naturally slowed developers down enough to think about what they were doing.

AI removes that friction.

You can go from idea to code almost instantly. The temptation is to skip the thinking stage entirely and just see what happens.

That usually produces one of two outcomes.

Sometimes the AI gets lucky and produces something close to what you wanted.

More often, it produces something that technically works but does not quite fit the system. The architecture drifts, patterns diverge, and small inconsistencies begin to accumulate.

The loop prevents that drift.

It creates a structure where AI accelerates implementation but does not replace architectural thinking.

Step one: the idea

Every change starts with an idea.

A feature request.

A bug report.

A new capability the product needs.

The temptation is to jump straight to implementation.

Instead, the idea should first be examined in the context of the system.

Where does this belong?

Does the system already contain something similar?

Is this actually the right feature?

AI can help answer those questions, but it should not start writing code yet.

The first step is always understanding.

Step two: architecture review

Before any implementation happens, the system should be examined.

This means looking at the current architecture and asking:

How does this part of the system work today?

What services, components, or models already exist?

What patterns are already in place?

AI can be surprisingly good at this stage. When asked to scan a repository and explain the relevant architecture, it can quickly surface relationships between files and components that might otherwise take time to rediscover.

The goal is not to change anything yet.

The goal is to understand the system before touching it.

Step three: the implementation plan

Once the system is understood, the next step is to define the smallest safe change.

A good implementation plan answers a few key questions:

Which files need to change?

What new code needs to exist?

What existing patterns should be reused?

What should not change?

This step is where AI becomes particularly useful. The model can propose a structured plan that outlines the steps required to implement the idea while preserving the existing architecture.

But the plan should always be reviewed by a human before implementation begins.

This is the moment where architectural mistakes are easiest to catch.

Step four: AI implementation

Only now does the AI begin writing code.

Because the plan is clear, the implementation phase becomes dramatically faster. The AI knows what it is supposed to build, which files to touch, and what patterns to follow.

This is where AI shines.

Tasks that used to take hours — scaffolding routes, wiring handlers, creating models, generating types, and writing tests — can now happen in minutes.

The key is that the AI is implementing a plan, not improvising.

Step five: testing

Implementation is never the end of the loop.

Every change must pass through testing.

Type checks, automated tests, and manual verification all play a role here. AI can help generate tests, but the human still needs to validate that the behaviour matches the intention.

Testing acts as the control layer that prevents fast implementation from becoming fast mistakes.

If something breaks, the loop simply runs again.

Step six: iteration

Software development is not linear.

The result of one change often reveals a better version of the same idea. Maybe the architecture can be simplified. Maybe the feature belongs in a different place. Maybe the product should evolve slightly.

The loop makes iteration natural.

Each pass through the cycle refines the system without losing coherence.

Instead of chaotic bursts of AI-generated code, development becomes a controlled series of improvements.

Why this loop scales surprisingly well

One of the most interesting things about the AI development loop is how well it works for a single developer.

Because AI handles much of the mechanical implementation, the human can spend more time on the higher-leverage parts of development:

understanding the system

making architectural decisions

reviewing plans

testing outcomes

This is one of the reasons the idea of a “dev team of one” is becoming more realistic.

The loop turns AI into a multiplier for thoughtful engineering rather than a replacement for it.

The real lesson

The most important shift in AI-assisted development is not that AI writes code.

It is that developers now have the ability to separate thinking from implementation more cleanly than ever before.

When that separation is respected, the results are powerful.

When it is ignored, the result is chaos.

The AI development loop is simply a way of keeping those two worlds in the right order.

Think first.

Build second.

Repeat.

Forem: Gleno

What's your stack?

The core stack items

1) JavaScript

2) TypeScript

3) React

4) Next.js

5) HTML

6) CSS

7) Tailwind CSS

8) Node.js

9) npm / pnpm

10) Supabase

11) PostgreSQL

12) SQL

13) Auth

14) Vercel

15) Tauri

16) Rust

17) SQLite

18) JSX / TSX

The default stack combo I’ve mostly been using

Web app / SaaS

Desktop app

The plain-English mapping

TL;DR

When the Cure Is the Disease: New Zealand’s Health IT

Why New Zealand’s Health IT Systems Are Such a Mess (And Why Fixing Them Is So Hard)

Table of Contents

The Origin of the Problem: 20 Separate Health Systems

The Regional Cluster Attempt

Legacy Systems That Never Die

The Hidden Monster: Integration

National Systems Layered on Top

The Attempt to Modernise

Why the IT Job Cuts Became Controversial

What Hospital IT Architecture Actually Looks Like

Final Thoughts

5ive ways to make good AI code exceptional

Table of Contents

Why this matters

1. Keep scope brutally clear

2. Give your model a stronger quality bar

3. Make it critique itself before and after

4. Separate build passes from polish passes

5. Make it work against a reference standard

The playbook

Review every summary properly

Ask for rationale on UI tasks

Keep a quality debt list

Make it do a cleanup pass

Force human-grade restraint

For UI/UX specifically

The biggest unlock

My role in all this

My strongest recommendation

Final thought

I reviewed a lot of chatter about AI-assisted engineering (vibe-coding) and it's a little scary TBH

AI-assisted engineering, SaaS anxiety, and the new mood in software

Gleno ・ Mar 13

AI-assisted engineering, SaaS anxiety, and the new mood in software #Episode 1

Table of Contents

My take

Articles and blogs

Themes showing up across the debate

1. The moat is moving, not disappearing

2. Weak SaaS looks shakier than strong SaaS

3. “Can build” and “can run” are diverging

4. The winners may look more like operators than coders

Final thoughts

Claude's take on the Slawk Codebase (14-day build)

Engineering Review

Overall Assessment: B+

What is strong

1. Security posture is materially better than average for a fast build

2. Input validation is consistently applied

3. Transaction boundaries are correctly used

4. Architecture is clean and understandable

5. Test coverage is meaningful

Real issues