9.6.2026 – “One Feature, End to End”

I want to show you what AI-native development at fter.io looks like in practice. Not a diagram. One real feature, from ticket to production.

The ticket
An external work order form accessible via QR code placed in public locations. A building manager scans the code, lands on a form, and reports an issue directly. Simple from the outside. Surprisingly complex underneath.
The moment you put a form in a public place, the considerations multiply. Who can submit? How do you prevent spam? What data can you collect without authentication? How do you tie the submission to the right asset without exposing internal identifiers in the URL?

Plan
The ticket went into JIRA with full context. Claude Plugins surfaced three security flags before a single line of code was written.
First: anonymous access patterns — the form needed to work without a logged-in user, but submissions had to be securely tied to the right asset and tenant. Second: rate limiting and abuse prevention — a public QR code is an open invitation without proper controls. Third: data minimisation — what is the minimum needed to route the submission, and what must not appear in the URL or payload.
Those flags would previously have surfaced mid-build or post-launch. They surfaced at planning. That is where they cost minutes, not weeks.

Design
Claude Design already knows our design system. The form component was generated aligned to our typography, colour tokens, and interaction patterns — adapted for a minimal, mobile-first public surface. The designer reviewed and refined. First review passed.

Code
The QR code encodes a short-lived signed token rather than a raw asset ID — so the link works without exposing internal identifiers. Rate limiting was built into the first version, not added after the first abuse incident.
The hardest part was prompting with enough security context that Claude understood the threat model, not just the happy path. That is the skill we are still building.

Test
Playwright generated the E2E test cases as part of the build — including the edge cases. Expired tokens. Fifty submissions from the same IP in a minute. Payload manipulation. Every one caught before the PR was opened.

Deploy
The PR included the ticket, the security decisions made at planning, the design review, and the test results. The reviewer had full context without asking for it. Deployment was clean.

Before vs now
Before: two sprints, security redesign mid-build, rate limiting added after the first incident, bug reported by a building manager on a Monday morning.

Now: one sprint, security model right from the start — not because the developer was more careful, but because planning forced the right questions before any code existed.

We are still tuning this. Not every feature flows this cleanly. But on the features where security matters most, the ecosystem is proving its value earliest.

29.5.2026 – Five Things That Are Already Working

We are mid-journey building an AI-native development ecosystem at fter.io. Last week I shared the challenges. Today I want to share what we are learning along the way because even the lessons from an incomplete rollout are worth sharing.

Five things that are already proving to be the right calls.

1. Treating security questions as design input, not resistance
   When the team first raised concerns about Claude — what data goes to the model, where it gets logged, who can see it — my instinct was to treat it as resistance to change. It wasn’t. Those questions are forcing us to design proper guardrails before anyone uses the tools in production. The teams asking the hardest questions are becoming the most thoughtful users. That pattern is already clear.
   
   
2. Connecting the design system to the code repo from day one
   Most teams keep design and code as separate sources of truth and accept that they will drift. We connected them directly — Claude Design knows our design system, Claude Code generates components aligned to it. Early results show significantly less back-and-forth between design and implementation. We are still measuring the full impact but the direction is clear.
   
   
3. Making architectural standards retrievable, not readable
   Standards in documents do not get followed — we all know this. By moving our architectural patterns, design tokens, and code conventions into the RAG pipeline, compliance is becoming a property of the system rather than a discipline. Developers do not need to remember the standards because the AI applies them automatically. This is working better than we expected.
   
   
4. Piloting with one team, not the whole organisation
   The temptation was to roll everything out at once. Instead we started with one team, embedded with them, and are fixing the rough edges where real developers actually hit them. The slower start is already saving us from shipping a half-finished platform to everyone. What we expand next will be a working system, not a beta.
   
   
5. Measuring adoption, not capability
   Early on we were excited about what the tools could do. We quickly learned the only metric that matters is whether developers actually use them for real work. Capability without adoption is just a demo. Daily active use, time saved per ticket, and team feedback are telling us a much truer story than any benchmark.

The pattern we are seeing:
The wins so far are not technical. They are about engineering the conditions for the technology to land — the trust, the guardrails, the workflow design, the rollout approach. The actual AI tooling is turning out to be the easy part.
We are not done. But we know what we are doing and why. I will keep sharing as we go.

What has worked for your team that you did not expect? Genuinely curious — these conversations are the most valuable part of building in public.

9.5.2026 – The impact looks very different from each seat

In my previous post I talked about the AI-powered development ecosystem we are building at fter.io. Today I want to share what it actually changes depending on where you sit in the team.

Because the impact looks very different from each seat.

For the Product Owner – the biggest shift is that requirements no longer get lost in translation. When a PO writes a ticket, that context flows directly into the AI workflow. Claude has the requirement when generating code. Fewer misunderstandings. Fewer cycles back to clarify. And because the system accumulates context over time, product knowledge stops living only in people’s heads.

For the Product Designer – the gap between what you designed and what gets built gets significantly smaller. We connected our design system directly to our code repository. Claude Design identifies components that exist in design but are missing in code and creates them. Implemented. Aligned to our patterns. The design system becomes a living source of truth, not a Figma file that developers interpret differently every time.

For the Developer – context is already there when you pick up a ticket. Generated code fits how your team builds aligned to your design system, your architecture standards, your conventions. Reviews are structured and not blocked by who happens to be available. And tests are part of the build, not an afterthought added under pressure at the end of a sprint.

For the QA Engineer- quality stops being a phase and starts being a property of the system. Automated tests are generated during development, not requested after it. Edge cases that are easy to miss under time pressure get caught early. By the time something reaches a tester, it has already passed through multiple AI-assisted quality layers. The role does not disappear it gets more interesting.

The common thread across all four? AI does not replace the judgment that each role brings. It removes the friction that gets in the way of doing that job well.

One architecture. Four very different impacts.

What’s on your mind regarding all this?