27.7.2026 – Lessons I have learned leading the AI transformation at fter.io

I have spent several months leading an AI transformation. I have written about the architecture, the challenges, and what is working. Today I want to share what it taught me about leadership. Because that is the part nobody writes about.

I started this as a technical problem. I thought the hard part was choosing the right tools, designing the right architecture, building the right integrations. Those things are hard. But they were not the hard part.

The hard part was people. The moment that changed how I thought about this. Early in the rollout, one of our senior developers quietly stopped using the tools after the first week. When I asked why, the answer was honest: he did not trust the output. Not because it was wrong — because he could not tell when it was wrong. He had no mental model yet for where AI judgment ended and where his own needed to begin.

That conversation changed everything. I had been optimizing for capability and assuming trust would follow. It does not work that way.

What I learned
The people who ask the hardest questions are your most valuable asset. Every concern raised before rollout is a production incident you did not have.
Adoption is the only metric that matters. A system developers do not use is not a platform — it is a proof of concept. Daily active use, real work completed with AI assistance, whether it makes people’s actual jobs easier. Everything else is vanity.

Speed of rollout is not the goal. Depth of adoption is. One team genuinely transformed is worth more than five teams nominally using the tools.
The hardest decision is not what to automate. It is what not to automate. The moments that require judgment and human accountability must be protected. Get that line wrong and you do not just lose productivity — you lose trust in the entire system.

Your own uncertainty is an asset. Saying “I am not sure, let us find out together” built more trust than any confident declaration would have.

What I would tell myself at the start
Spend the first month listening, not building. The tools you build to solve imagined problems will not get used. The tools you build to solve real ones will not need to be evangelised.
And be honest about the journey. The posts I have written about challenges and incomplete rollouts have generated more genuine conversation than the ones about what worked. Honesty is the most underrated leadership tool in technology.

Where this leaves me
I am a better technical leader because of this work — not because the technology is impressive, though it is, but because leading this transformation forced me to get better at the things that were always more important than the technology.

Trust. Communication. Listening. Knowing when to move fast and when to slow down. Those are what make or break any transformation. AI just made them more visible.

20.7.2026 – What’s Next for Our AI Ecosystem

I have spent several posts sharing what we built, who it affects, what has been hard, and what is working. Today I want to share where we are going next. Because the foundation is in place. Now comes the interesting part.

Phase 1 is done — the connected workflow at fter.io
Claude Plugins for planning. Claude Design for design. Claude Code for development. Playwright for testing. A CI/CD pipeline that carries context end to end. The paved road exists. Developers are using it for real work. What we built in phase 1 was infrastructure. What we build in phase 2 is intelligence. What comes next.

Smarter context, not just more context
Right now our RAG pipeline feeds architectural standards and design tokens into the AI tools. It works. But the retrieval is still relatively broad — the AI gets the standards, not necessarily the most relevant standards for the specific decision being made.
The next step is a more precise metadata schema. Matching retrieval context to decision type. Code generation gets design tokens and architecture patterns. Review gets the specific standards it is reviewing against. Planning gets historical decisions and business context. Right context, right moment, right decision.

Agent-to-agent workflows
We have AI assisting humans at every step. The next evolution is AI assisting AI. Agents that hand off to other agents — a planning agent that creates a structured brief for a coding agent, which generates output that a review agent validates before a human ever sees it. We are in early exploration on this. The architecture is designed for it. The question is where human oversight belongs in the loop and where it does not.

Measuring what actually matters
We track adoption. We know developers are using the tools. What we do not yet measure well enough is business impact — cycle time reduction, defect rates, feature throughput. Phase 2 includes building the measurement layer that turns anecdotes into evidence. Without that, we cannot make the next investment decisions with confidence.

Expanding to more teams
The pilot team proved the model. We are now expanding to a second team with a different workflow and different constraints. Every new team reveals something the first team did not. That is valuable data we cannot get any other way.

The honest caveat
None of this is certain. AI tooling is moving faster than any roadmap. Some of what I just described will look different in six months because the tools will have changed. The principle stays constant — build the conditions for AI and humans to work together well. The implementation will keep evolving.

I will keep sharing as it does.

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?

1.5.2026 – AI-Powered Development Ecosystem

We are building a software development ecosystem powered entirely by AI. Here is the architecture.

Most engineering teams I talk to are using AI the same way — a coding assistant here, a chat tool there. Useful, but disconnected. Each tool does its job in isolation. The workflow between them is still manual.

We decided to go further beyond the horizon
At fter.io, we are rolling out a connected AI ecosystem that spans the entire software development lifecycle. From the moment a feature is planned to the moment it is deployed, AI is embedded in every step — not as a point tool, but as the intelligent layer connecting them all.

Here is what the stack looks like:
→ Plan — Claude Plugins drive sprint planning, engineering reviews, and code reviews. The decisions that used to live in meetings now have structure, context, and AI input from the start.

→ Design — Claude Design is our design environment, connected to our design system and code repository. Components are consistent across design and implementation. One source of truth for everyone.

→ Code — Claude Code generates code that is already aligned to our design system, our architecture standards, and our existing patterns. Not generic output — code that fits how we build.

→ Test — Playwright handles automated testing, integrated into the flow. Quality is built in from the start, not added at the end.

→ Deploy — The pipeline connects everything so that the journey from ticket to production is automated, auditable, and consistent.

Claude is the intelligent layer running through all of it — connecting plan, design, code, test, and deploy into a single coherent workflow.

One thing that surprised us: because Claude has access to the full context — tickets, design system, architecture standards, code history — it is also building product knowledge automatically. The system understands what has been built, why decisions were made, and how components relate. That institutional knowledge no longer lives only in people’s heads.

We are still rolling this out. It is not perfect. Every ecosystem like this takes time to tune — because the hardest decisions are not about the tools. They are about the workflow itself: what AI should own, what humans should own, and where the handoffs happen.

But the direction is clear. The future of software development is not AI assisting humans at individual steps. It is AI embedded in the entire flow, with humans focused on the decisions that require judgment.

Next I will share what this changes for Product Owners, Product Designers, Developers, and Testers — because the impact looks very different from each seat.

20.4.2026 – Claude Assisted Development

We introduced AI-assisted coding to our engineering team. Here’s what actually happened.

A few months ago I proposed we trial Claude as a day-to-day development tool. Not just for generating boilerplate — but deeply embedded into how we work: code review, system design, documentation, and testing.

The first reaction from the team wasn’t excitement. It was concern.

“What happens to our code if it goes through an external AI?”
“How do we know it isn’t being used to train a model?”
“What about our clients’ data?”

Security was the biggest blocker — and rightfully so. Before a single developer used it in production, we had to answer those questions properly. We reviewed Anthropic’s data usage policies, defined clear guidelines on what could and couldn’t be shared with the model, and established team norms around handling sensitive business logic.

Once trust was established, adoption was fast.

Here’s what the team uses it for today:

→ Code review: catching issues before they reach pull requests, not just style but logic and edge cases
→ Design: thinking through architecture options, challenging assumptions, exploring tradeoffs
→ Code generation: accelerating repetitive or boilerplate-heavy tasks without sacrificing quality
→ Documentation: turning complex implementations into clear, maintainable documentation
→ Testing: generating test cases, including edge cases developers might not think to write

What changed after adoption?

— Faster delivery: the team moves noticeably quicker on tasks that previously required significant research or iteration
— Fewer bugs: having an AI reviewing logic before code is committed catches a surprising number of issues early
— Better onboarding: new developers get up to speed faster when they can query the codebase and get contextual explanations instantly

The biggest lesson: AI-assisted development is not about replacing engineers. It’s about removing the friction that slows good engineers down.

The engineers who embraced it didn’t become less technical. They became more effective.

If you’re leading an engineering team and haven’t explored this yet — the barrier is lower than you think. The harder work is the change management, not the tooling.

Happy to share more about how we structured the rollout if anyone is considering something similar.