At Kaizen Softworks, the adoption of AI tools is a central topic. To efficiently manage their usage and licensing requests, we created an internal form. However, the classic problem with this type of workflow is misalignment. Collaborators often have very specific questions about internal policies or need to validate their use cases against documentation that is scattered across various drives or wikis.

The goal was to prevent team leaders from becoming the "human knowledge base" for every request, which creates a bottleneck. We needed a conversational AI assistant that could combine the answers from a form with dynamic knowledge, delivering accurate and verifiable responses. This is where FormBot was born.

What is FormBot? An Integrated Conversational Experience

At a high level, FormBot is a solution that integrates a multi-step form with an accompanying chat assistant. The user interacts with a dual interface: while completing the form fields, they can converse with a bot to resolve questions in real time.

The experience is centered on two key capabilities:

• Form Context Awareness: The chat has "awareness" of the answers the user is completing. This eliminates the need for the user to repeat information, creating a truly fluid and intelligent experience.
• On-the-Fly Expandable Knowledge: The user can upload a document (an internal policy, a project guide, etc.) and, in seconds, the bot ingests that knowledge. When the user asks a question, the bot now provides a detailed and verifiable answer, citing the exact fragments of the document as sources to ensure maximum reliability.

The Challenge: Privacy and Data Isolation in Generative AI

When handling internal documents from different users and teams, knowledge isolation is a non-negotiable requirement. A user who uploads their team's policies must never be able to access or influence the knowledge base of another user who is uploading documentation for a different project.

This need for absolute privacy was the pillar upon which we designed FormBot's entire technical architecture, ensuring that every interaction was completely private and isolated.

Our Architecture: Multi-Tenant RAG with LangChain and Pinecone

To achieve robust data isolation and a fluid experience, we built FormBot on a RAG (Retrieval-Augmented Generation) architecture with a multi-tenant focus.

The Technology Stack

We selected a set of flexible and powerful tools to bring FormBot to life:

• AI/Orchestration: An OpenAI LLM (GPT-4) for reasoning and natural language processing.
• Vector Database: Pinecone, specifically chosen for its native capability to isolate user documents via namespaces.
• RAG Framework: LangChain, to orchestrate the entire flow of document ingestion, information retrieval, and response generation.
• Language: JavaScript.
• Infrastructure: Deployment on AWS/Cloud.

Total Isolation with Namespaces

The RAG concept involves using a retriever (in our case, Pinecone) to fetch relevant data from a knowledge base before sending the question to the LLM. This ensures that the answers are based on verifiable information and not on the model's general knowledge.

To guarantee privacy, we implemented a total isolation process using Pinecone's Namespaces. Here is how it works:

1. Identification: Upon initiating the flow, the user's email is captured.
2. Namespace Generation: This email is used to derive a unique and private namespace within Pinecone (for example, email-kaizen-softworks-com). A namespace functions as an isolated container for the data.
3. "On the Fly" Indexing: When a user uploads their documents, LangChain's ingestion process processes and indexes the embeddings (vector representations of the text) exclusively within their derived namespace.
4. Isolated Retrieval: When the user asks a question, the RAG layer only performs the vector search within their own namespace. This ensures there is no possibility of data leakage or cross-contamination of knowledge between users.

How Does "On the Fly" Indexing Work?

"On the fly" indexing means the bot learns instantly from the knowledge the user provides at the moment they are completing the form. This is the process that allowed FormBot to go from not knowing what Kaizen Softworks is, to providing a detailed, sourced answer in a matter of seconds.

The flow is as follows:

1. The user uploads a document (PDF, DOCX, etc.) via the interface.
2. The document is automatically split into manageable text fragments (chunks).
3. The embeddings for each fragment are generated using the AI model.
4. These embeddings are sent to Pinecone and stored under the user's specific, private namespace.

This dynamic flow is the basis for scaling the solution to other departments like Human Resources or IT Support, where policies and documentation may be specific to a small group of people and change quickly.

Building internal AI tools? 

Get in Touch to explore how to build privacy-first AI for your organization.

LET’S TALK

‍

"What if we could build an app in days instead of weeks, using AI not just as a feature, but as a full-stack development partner?"

That's the question that sparked Super Ultra Kiosco, a proof of concept (POC) that digitized our company's beloved manual snack corner using the latest AI development tools.

We sat down to document exactly how we used tools like Figma MCP (Model Context Protocol) and Vercel AI SDK to build a working product detection system.

Let's start with context: What exactly is "Super Ultra Kiosco"?

In our office, "El Kiosco" is a small corner with snacks, drinks, and other goodies. The system was manual: grab an item, find the shared spreadsheet, and manually log your debt. It was error-prone, tedious, and ripe for modernization.

The Solution: A mobile-first web app where you simply point your phone at the snacks. AI identifies the products via camera, calculates the total, and confirms your order with one tap. No spreadsheets, no typing.

The tech stack behind this AI-native app

To achieve this, we moved beyond standard web development into an AI-native workflow. Here is the core technology stack:

• Framework: Next.js with TypeScript.
• AI Vision & Logic: Vercel AI SDK (powered by Google Gemini Vision) for the product detection feature itself.
• Design-to-Code: Figma MCP for translating designs into code.

This combination allowed us to treat the AI as a collaborator that could "see" our designs and "understand" our business logic.

‍

How does product detection with Vercel AI SDK work?

The "magic" of the app is its ability to recognize a bag of chips or a soda can instantly. For this, we used the Vercel AI SDK coupled with Google’s Gemini Vision model.

Traditional AI integrations often struggle with unstructured text responses. We solved this using the SDK's generateObject function. This allows you to define a schema (using Zod) to force the AI to return structured, typed JSON data instead of a conversational string.

Here is the actual implementation code:

JavaScript

const result = await generateObject({

  model: google('gemini-2.5-flash'),

  messages: [

    {

      role: 'user',

      content: [

        { type: 'text', text: prompt },

        { type: 'image', image }

      ]

    }

  ],

  schema: AnalysisResultSchema,

  temperature: 0.1

});

The Trade-off: Using the AI SDK provides incredible flexibility to switch model providers (e.g., swapping Gemini for GPT-4o) without rewriting code. However, if you need bleeding-edge features specific to a provider—like accessing a brand new beta model or a very specific configuration—you might find it limited. You gain high availability of providers, but you might have a smaller pool of models available within each provider compared to using their native SDKs.

‍

What about Figma MCP? How did that fit into the workflow?

Figma MCP (Model Context Protocol) creates a bridge between your Figma designs and your AI coding assistant (like Windsurf or Cursor).

In technical words, Figma MCP is a standard that connects AI assistants directly to external data sources. The Figma MCP server exposes your actual design files—component properties, layout tokens, and visual hierarchy—as a resource the AI can "read."

​​Instead of us manually coding CSS from mockups, the workflow looked like this:

1. We designed the UI in Figma.
2. Our IDE (via MCP) "connected" to the design file.
3. We prompted the AI: "Build this product card component based on the 'Mobile Card' frame in Figma."
4. The AI generated React components that matched our design specs (almost) perfectly.

Key Learning: While Figma MCP helped us move fast, it wasn't magic. We found that we still had to iterate a few times to match the designs 100%. The AI captures the general structure well, but it can fail on specifics like exact paddings, button states, or color nuances. It gets you very close, but the final polish to ensure the implementation matches the design perfectly still requires a developer's eye.

What was the most surprising part of building with these AI tools?

Building Super Ultra Kiosco validated four core hypotheses about the state of AI development:

• Speed: We moved from concept to working prototype in just 6 hours, a fraction of the time it would normally take. The structured output from Vercel’s SDK removed the need for complex parsing logic.
• Context is everything: When using AI assistants for development, providing good context (whether through MCP or clear instructions) dramatically improves results. With AI SDK giving us structured outputs and Figma MCP ensuring design fidelity, we spent less time on boilerplate and debugging, and more time on the actual product experience.
• Prompt engineering is still an art: Even with structured outputs, crafting the right prompt for product detection took iteration.
• Image quality matters: The AI detection works best with good lighting and clear photos. We added image compression to balance quality vs. API costs.

‍

Q&A: Common questions on AI-assisted development

Is Figma MCP ready for production apps? It is excellent for rapid prototyping and setting up component libraries. For complex, custom animations or highly specific accessibility requirements, human oversight is still mandatory.

Why use Vercel AI SDK instead of the official Google SDK? For a POC or a multi-model application, Vercel AI SDK offers a unified API that saves significant time. If your app relies 100% on unique, deep features of a single model (like Gemini's 1M context window specific caching), the native SDK might be better.

What is the cost implication of using Vision models for this? Vision models are more expensive than text models. We implemented client-side image compression before sending requests to the API to balance performance and cost.

Building something similar? 

We'd love to hear about your experience with AI development tools.

LET’S TALK

‍

"I’m still learning how to integrate these new AI tools into my actual daily workflow." That’s probably one of the phrases every UX designer is repeating right now.

The promise of Figma’s "Prompt to Edit" feature is incredible, but the operational reality can be... different. At first, I struggled to understand how to get real value out of it without feeling like I was wasting time.

This article documents how I transformed a frustrating "trial and error" process into an efficient workflow using a technique called Meta-Prompting.

Why is iterating with Figma's AI agent so difficult?

I started exactly how we all do: typing exactly what I needed directly into the Figma prompt bar.

• My Prompt: "Change this section to a three-column grid."
• The Result: Acceptable. A decent starting point.

The real challenge emerged when I tried to iterate. I quickly realized that Figma’s current agent struggles to interpret chained corrections. If I asked it to adjust a specific section, it would often "hallucinate" and alter elements that were already perfect, or the final design would lose visual coherence.

I felt like I was running in circles, spending more energy explaining the changes to the AI than it would have taken to just design them manually. My direct approach wasn't working.

How can ChatGPT help create better Figma prompts?

I realized the problem wasn't the tool, but the lack of structure in my request. Figma’s AI needs dense, precise context in a single shot to function effectively.

I decided to test Meta-Prompting.

What is Meta-Prompting in Design? Instead of trying to craft the perfect prompt myself ("User to Tool"), I use a conversational LLM (like Gemini, ChatGPT or Claude) as an intermediary ("User to AI to Tool").

‍

What does a Meta-Prompting workflow look like in practice?

1. Context: I explain to ChatGPT exactly what I want to achieve, the visual style, and the requirements.
2. Generation: I ask ChatGPT to generate a highly detailed, technical, structured prompt specifically for the Figma agent.
3. Execution: I copy that prompt and paste it into Figma.

It was a learning process, but the results were immediate. It is far more effective to iterate the text in ChatGPT until the logic is bulletproof, and only then pass it to Figma for clean execution.

Does the quality of your Design System affect AI results?

There is a second variable in this equation: the quality of your base file. We learned that AI cannot perform magic if the underlying structure is chaotic.

• With unpolished systems: The result is poor and inconsistent.
• With robust systems: When we decided to use the Kaizen Softworks Wireframe Kit, the quality improved dramatically.

Why? Because the agent finally had solid components (with Auto Layout and properly named variants) to "latch onto." The AI understands logical structures better than loose pixels. 

(Technical Note: Even with a good system, we found bugs. For example, the agent still struggles to correctly map FontAwesome icons, often requiring manual adjustment).

What are the key takeaways for AI-assisted design?

If you are struggling with design agents, consider these points:

• Context is King: You don't always need the design tool to have the best chat interface. Sometimes, the key is managing that context externally (in ChatGPT) and importing it.
• One-Shot vs. Iteration: Figma works better with complete, robust instructions from the start (One-Shot) rather than a long chain of small corrections.
• Garbage In, Garbage Out: If your design system lacks clear naming conventions and structure, the AI won't be able to infer the logic.

‍

Q&A: Common Questions on Figma AI

Is "Prompt to Edit" ready for complex projects? For generating initial structures or rapid variations, yes. For final "pixel-perfect" polish, human oversight is still mandatory.

What is a "One-Shot Prompt"? It is a single instruction that contains all necessary information (style, constraints, content) for the AI to complete the task in one attempt, without needing follow-up questions.

Why use ChatGPT to write Figma prompts? Language Models (LLMs) are better at structuring logic. They ensure your prompt is unambiguous, preventing Figma's agent from misinterpreting your intent.

How do you handle iterations with design agents? 

Have you found a seamless workflow, or are you still in the trial-and-error phase like me?

‍

At Kaizen, we don’t believe software quality is enforced by a checklist or a single gatekeeper. It’s something we build together, day in and day out, as a team.

We’ve been working on this platform for years. What started with two developers has grown into a 30+ person team building a large-scale logistics system. And like any growing team, we faced a big question:

How do you keep quality high without turning into a slow, over-regulated machine?

We chose trust over set in stone rules. And in doing so, we learned something simple but powerful: Our strongest safety net isn’t a process. It’s each other.

A Team That Catches Each Other

When systems get complex, legacy code, multiple teams, tight deadlines, it’s tempting to respond with more rules. But heavy oversight kills initiative. Instead of building a team that takes ownership, you get one that’s just trying not to mess up.

We took a different approach. We built a system where quality doesn’t rest on one person, it’s shared, distributed, and reinforced by the people around you.

Code review is just one part of that system, but it’s where this mindset comes to life.

​​Code Review as a Conversation

For us, code review isn’t about nitpicking, it’s a technical conversation between teammates.

When I open a PR, I’m not bracing for criticism. I’m inviting collaboration. Together, we’re asking: “Are we solving this clearly, cleanly, and in a way that makes life easier for the next person?”

Code reviews are done by other developers from the same sub-project. That means the person reviewing already has context, and because the reviewer role rotates, everyone gets to both give and receive feedback. It’s collaborative by design, and part of how we grow as a unit.

We review with a few key principles in mind:

• Clarity over cleverness: Can someone new understand this without a full-day walkthrough?
  
  
• Don’t reinvent the wheel: Are we duplicating logic that already exists? If so, we flag it and refactor.
  
  
• Performance with perspective: Are we making smart decisions, like reducing unnecessary database calls?

We refer to our internal Wiki often, not as a rulebook, but as a shared language.

Ownership Starts with One, Backed by All

One of our core beliefs:
“Ownership starts with the person who says it’s done, but quality is everyone’s job.”

We say it often: “The ownership falls mainly on the person who tests it and says it’s okay.”

It’s not about blame. It’s about trusting each dev to be accountable, knowing the team has their back. That shared responsibility creates a culture where people step up, not out of fear, but because they’re supported.

What Happens When Something Slips?

Let’s be honest: we’re human. Not every issue gets caught in review. But that doesn’t break our system, it proves why it works.

Because someone else will catch it later. And when they do, they won’t ignore it, they’ll flag it, fix it, and keep moving.

We log cleanup tasks in our tech debt backlog. It’s not a black hole, it’s a to-do list for continuous improvement. A way to keep tightening the net.

Reviews Are Where We Grow

In our team, code review it’s where learning happens.

New devs get real-time, contextual feedback. Seniors reflect on their habits. We share ideas, challenge each other, and improve as a unit. It’s ongoing, hands-on knowledge transfer, baked into the flow of work.

We don’t trust the code because it’s perfect. We trust it because of how it’s built:
by a team that shows up, collaborates, and looks out for each other.

In the End, It’s the Team

Our confidence doesn’t come from tools or top-down rules. It comes from people who care. People who ask questions, challenge decisions, and leave the codebase better than they found it.

The team is the system. The team is the process. The team is the safety net.
And when that’s in place, you can scale without fear.

"Stack Overflow on steroids." That’s the best way to describe it. But is AI the ultimate productivity hack, or just a faster way to create complex code? From parsing tricky regex in seconds to figuring out how much context to feed the bot, integrating these tools is a skill we are all learning in real-time.

I sat down (virtually) to discuss the art of prompt engineering and the nuances of relying on generated solutions. We dive into why using AI effectively isn't just about getting answers, it's about knowing how to ask the right questions to build better, sustainable software.

‍

*Note: This interview with Dan was conducted by Claude, an AI assistant. Yes, the irony of using AI to discuss using AI is not lost on us.*

Let's start with the basics: How would you describe AI as a development tool in one sentence?

"Stack Overflow on steroids" - honestly, that's what it is for me. It's like having that incredibly knowledgeable senior developer available 24/7, but you need to know how to talk to them.

So where does AI for developers shine day-to-day?

For quick, isolated problems, it's incredible. Need to parse a tricky regex? Convert between date formats? Understand an error message? Just ask. No context needed, instant answer. These small, specific queries are where AI shines brightest with minimal effort.

What are the downsides of using AI for coding?

The big challenge is context, especially for larger projects. That's where things get interesting - and harder.

Tell me about context. How did you initially approach giving context for bigger features?

My initial approach was exhausting. I'd dump everything into the prompt: "Here's my entire file structure, here's the relevant code, here's what I'm trying to do..." I'd spend 10 minutes crafting a prompt, constantly worried I'd forget some crucial detail. It worked, but it was draining.

So what changed? What's a better approach to prompt engineering?

A fellow developer showed me a completely different approach: let the AI build its own context through questions. Instead of front-loading everything, you start with something simple like "I need to add authentication to my Express app," and the AI asks what it needs to know - what auth strategy, existing middleware, whatever. The conversation naturally builds the needed context. You only provide what's actually relevant.

That's a smart approach. Has that solved the context problem for you?

Honestly? I'm still figuring it out. The truth is, I still struggle with prompt engineering. For larger features or refactors, I haven't found the perfect workflow. Sometimes the "let AI ask questions" approach works great. Other times, I need to provide upfront context. It really depends on the complexity and how well I can articulate what I need.

If prompt engineering is hard, why keep using AI?

Because it's not about getting complete solutions - it's about changing how I problem-solve. It's like having a knowledgeable pair programmer who's always available. The skill isn't in knowing everything anymore; it's in knowing what questions to ask and when to ask them.

What are you seeing around you? How are other developers using AI tools?

It's wild, honestly. I've seen colleagues build entire projects from scratch in just days, even hours. I've also seen someone migrate a whole Angular project to a newer technology without writing a single line of code themselves. It sounds amazing, right? 

But here's the catch - if you don't review what AI generates carefully, you can accumulate massive technical debt. The code works, sure, but it might not follow your team's patterns, might have hidden performance issues, or make architectural decisions that don't fit your specific needs. AI can move fast, but someone still needs to be the critical reviewer.

Final question - What's next for AI in development?

I'm still learning, we all are. The tools are evolving, and so is my approach to using them. But one thing's clear: understanding how to interact with AI is becoming as important as understanding the code itself. It's a skill we're all developing in real-time.

I’ve been on this project for years. I was here when "the team" was just two developers in a room, and I'm here now as part of a 30+ person force building a critical logistics platform for our client.

Most stories about scaling a dev team are war stories. They’re all about shipping fast, racking up technical debt, and eventually having to rewrite the whole thing from scratch. Ours is different. It’s about how a deliberate (some might say stubborn) commitment to code quality from day one helped us grow without burning ourselves later.

A Pact for Quality in a Sea of Legacy Code

When Kaizen joined this project, we weren't starting with a blank slate. We were tasked with merging and modernizing several legacy systems into one cohesive platform. The codebase had layers, each with its own quirks and logic. In that kind of environment, the “move fast and fix later” approach would’ve been a disaster.

We knew that if we wanted to build something scalable and sane to work with long-term, quality couldn’t be optional. It had to be baked in.

So from day one, we made it a rule: every single line of code gets reviewed. Whether it’s a new feature or a legacy refactor, it goes through a second pair of eyes.

We framed this to our client not as a slowdown, but as an investment. Spending an extra hour reviewing a PR, especially one touching old code, saves days (sometimes weeks) of tracking down weird bugs later. It was the only way to build a modern, maintainable codebase.

Fortunately, our client’s technical. They got it. And that trust? It became one of the most valuable things in our partnership. It gave us room to do things right, not just fast.

Making Code Reviews a Team’s Habit

We needed a process, a way to keep standards high, share knowledge, and catch issues early. So we built a structured code review system, grounded in Kaizen’s core principle: continuous improvement.

‍

This wasn’t about nitpicking or finger-pointing. It was about creating a feedback loop and turning every review into a learning opportunity.

Here’s what that looks like today:

• Dedicated Review Stage: When a dev finishes a story, it moves to “Code Review” in Jira. It’s not a nice-to-have, it’s a required step.
• Peer-Powered: Another dev from the same sub-project picks it up. They already have context and can give meaningful feedback. We use Azure DevOps to review, leave comments, and suggest changes.
• Beyond Just Bugs: We ask more than “does it run?” We ask:
  
  • Does it actually solve the problem the ticket described?
  • Is there a better, more efficient way to do this? (e.g., “Could these five DB calls be one?”
  • Does it follow our naming conventions and practices?
  • Is the code readable and maintainable for whoever works on it next?

Scaling the Blueprint

Going from 2 to 30 devs is one thing. Scaling a culture of quality across all of them? Way harder.

‍

Our code review process became the backbone of both onboarding and team growth.

• The Wiki = Our Shared Brain: Standards don’t work if they only live in someone’s head. We documented everything in an internal Wiki, from naming conventions to architecture decisions. Reviewers link to it often, turning corrections into coaching moments.
• Reviews as Mentorship: For new devs, their first code reviews are where the real onboarding happens. They get real feedback from teammates who know that part of the system inside and out. It’s how we share the team’s DNA. It's how we say, “This is how we do things here.”
• Same Rules for Everyone: Junior or senior, every dev’s code goes through the same review process. It keeps egos out of it and keeps the bar high across the board.

The Payoff: Growth Without the Chaos

Was this a quick win? No. It took time and buy-in. But the impact has been huge.

“I remember a case where we brought a function’s execution time down from 10 seconds to under three. The client was thrilled,” one of our devs shared. “That’s when it clicks. This isn’t just about ‘clean code’, it’s about delivering real value.”

‍

Some of the benefits we’ve seen:

• Reduced Rework: Catching logic errors in reviews cut down on production issues.
• More Trust: Our client saw the difference. They knew we weren’t just ticking boxes, we were building for the long haul. That made it easier for them to vouch for us internally and bring us more projects. 
• Better Knowledge Sharing: Juniors learned from seniors. Seniors got fresh eyes on their code. Everyone leveled up.
• Smooth Onboarding: With strong processes and a healthy codebase, bringing in new devs got easier. We could grow without sacrificing quality.

And yeah, we still have technical debt. We even have a “tech debt bucket” in Jira. But it’s not this ominous, growing monster anymore. It’s a manageable list. A conscious decision, not a side effect of bad habits.

Wrapping Up

Code reviews aren’t magic. They won’t solve everything. But done right, they can become the heartbeat of a team that cares about quality, about learning, and about building something that lasts.

That’s how we did it. That’s how we’re still doing it.

AI is evolving fast, and it's easy to get lost in the sea of online hype and conflicting advice. To help you cut through the noise and start building solid foundational knowledge, our Innovation Hub has curated a list of four essential books. Each one tackles a different but interconnected layer of the AI stack, offering the practical knowledge you need to stay ahead of the curve.

1. AI Engineering: Building Applications with Foundation Models By Chip Huyen

Get a complete guide to "AI Engineering," the new discipline of building powerful applications with readily available foundation models, and understand how it differs from traditional ML engineering.

This book teaches you how to:

• Understand the new AI stack and its key differences from traditional machine learning.
• Apply a complete framework for developing an AI application, from choosing the right models and datasets to efficient deployment.
• Use a wide range of model adaptation techniques, including prompt engineering, RAG, fine-tuning, and building agents.
• Implement different methods for evaluating open-ended models, including the modern "AI-as-a-judge" approach.
• Overcome common bottlenecks for latency and cost when serving foundation models in production.

2. Hands-On Large Language Models - By Jay Alammar

Jay Alammar moves past abstract theory and superficial prompts to teach you how to build modern, end-to-end AI applications. His famous visual style makes complex architectures and cutting-edge techniques easy to understand and implement.

This book teaches you how to:

• Understand the Transformer architecture that powers models like GPT.
• Build powerful semantic search systems that go beyond simple keyword matching, using methods like dense retrieval and rerankers.
• Use the full spectrum of generative models, from prompt engineering all the way to Retrieval-Augmented Generation (RAG).
• Train and optimize LLMs for your specific needs using techniques like fine-tuning and in-context learning.

3. AI Agents in Action - Micheal Lanham

This book takes you to the next level of AI development. It goes beyond simple chatbots to teach you how to build and orchestrate fully autonomous, production-ready AI agents. Micheal Lanham’s guide focuses on creating trustworthy systems capable of handling complex, real-world tasks like high-stakes negotiations.

This book teaches you how to:

• Create agents that can plan, collaborate, and self-improve using feedback loops.
• Implement robust knowledge management and memory systems for your agents.
• Orchestrate collaborative multi-agent systems using cutting-edge tools like AutoGen and CrewAI.
• Enhance your agents with multimodal capabilities, including speech and computer vision.

4. LLMs in Production - By Christopher Brousseau

Get a practical, example-rich guide that bridges the gap between a promising concept and a successful, scalable product, focusing squarely on the MLOps strategies needed for real-world deployment.

This book teaches you how to:

• Evaluate when to use a premade LLM versus building your own from scratch.
• Scale your MLOps platform to handle the unique demands of LLMs.
• Fine-tune, train, and deploy foundation models using advanced architectures like RLHF.

Keep Learning

The world of AI won't be slowing down. Getting grounded in the fundamentals is the best investment you can make in your career. We hope this list of AI books for developers gives you a clear starting point to take these concepts, experiment with them, and start creating

The Transportation Intermediaries Association (TIA) Technovations 2025 Conference in Phoenix, AZ, was a highly focused and valuable event. Held at the JW Marriott Phoenix Desert Ridge Resort & Spa, this gathering, while smaller and intimate with an estimate of 200 attendees, was a powerful showcase for the best of logistics technology.

The central theme was clear: Automation and AI are driving the industry forward, and the sheer volume of high-quality, off-the-shelf software available is impressive.

The Technovations Experience

The conference structure was engineered for engagement, primarily through product-focused interaction:

• Focused Showcases: The agenda featured multiple "Technovator Showcase" segments, where innovative software companies provided quick demos of their solutions.
• The Kiosk Ecosystem: The Kiosks, which served as the hub for the Networking Breakfast, Lunch, and Evening Reception, were populated exclusively by Software Product companies. This provided an ideal environment for meaningful, quick exchanges between vendors and attendees.
• Key Industry Insights: Panels stressed that technology evaluation should center on core business metrics: Differentiation, Revenue Increase, Scalability, and Protection.

The Unified Message: AI is the Cost of Entry

The consensus across the keynotes and educational sessions was clear: AI and automation are the cost of entry for survival and scaling.

• Automation vs. AI: A critical distinction was made: Automation is often a prerequisite for effective AI adoption. The goal isn't just to automate a task, but to use AI to smooth out high-volume, repetitive processes, like reformatting RFPs or triaging a sales team's worst 10 emails for managerial review, as highlighted by an attendee’s high-value use case.
• The AI Roadmap Dilemma: Many attendees and panelists are struggling with how to start an AI initiative. The advice was to abandon the idea of a massive, costly roadmap and instead focus on a small, measurable Proof of Concept (POC) that targets a specific pain point with clear KPIs. If you can’t measure the ROI, it’s not worth doing.
• A Word of Caution on Tech Adoption: Panelists stressed that technology failures are overwhelmingly due to the client specifically, their lack of preparation, poor data, or failure to commit to the change management process. They noted that implementing new tech can often feel like taking on a "second job" due to the integration and rollout time required.

The Customization Opportunity: Solving for the Unique

While the product ecosystem is robust, our conversations with leaders across the industry revealed a clear, unmet need:

• Top-tier TMS providers and logistics operators acknowledged that for many scaling $50M-$250M 3PLs, a standard product simply cannot address the 1-2 unique, complex operational processes that truly drive their differentiation and growth (e.g., highly specialized niches or proprietary client models).
• For these unique challenges, the best approach is often a tailored technology solution. This isn't about criticizing products; it's recognizing where the product lifecycle naturally reaches its boundary and a custom approach becomes necessary to avoid bottlenecks.

This is the true next step for growth: building proprietary technology that hard-codes a competitive edge directly into the business model.

How Kaizen Softworks Partners for Differentiation

At Kaizen Softworks, we partner with logistics leaders to:

• Pilot Custom POCs: We build targeted, measurable Proofs of Concept around your unique challenges, allowing you to quickly test and measure ROI on advanced AI or operational automation without the risk of a massive system overhaul.
• Engineer Proprietary Systems: We create tailored software that enhances your core differentiator, be it a specific carrier-sourcing model, a unique compliance layer, or a specialized "Cradle to Grave" client experience, ensuring your technology is a true competitive weapon.
• Ensure Alignment: Our focus on cultural fit, time-zone synchronization, and clear communication ensures that partnering on strategic development is smooth, effective, and less likely to feel like a "second job."

TIA Technovations 2025 confirmed that the logistics industry is healthy and focused on innovation. We look forward to working alongside our peers to help freight leaders build the tailored solutions necessary to thrive in the complex, digital landscape ahead.

At Kaizen, design critiques began as a simple idea for peer learning, but quickly became the most valuable part of our UX culture. Our philosophy is to build by co-building. Feedback isn’t something we fear; it’s something we train for. We prefer to face tough input at the right time rather than too late.

We use design critiques to connect, exchange perspectives, and train our critical eye. It's not about one UXer working alone; it’s about bringing diverse viewpoints together to strengthen ideas early, before they go live. We hold these sessions weekly across all projects, from small features to large redesigns.

What is a Design Critique (and How We Run Ours)

A design critique is a structured, collaborative review where peers evaluate a design, prototype, or concept. Its main objective is to gather constructive feedback to identify strengths and weaknesses, leading to significant product improvements.

Our sessions last one hour. One person moderates while others present their work. Each presentation is about 15 minutes, split evenly between context and feedback.

Every UX design critique follows a three-part structure. The core rule is that feedback must be objective analysis (e.g., based on user needs and UX principles) and never personal judgment:

1. The Critique Itself: Observations, reactions, and questions about the design.
2. The Theoretical Grounding: The reasoning behind the comment, often supported by heuristics or UX principles.
3. The Proposed Solution: A suggestion on how to address or refine the issue discussed.

The Dual Purpose of Our Critique Process

What makes the Kaizen design critique process unique is the dual purpose it serves:

• Training the Muscle of Critique: Every session is both practice and contribution. We grow as designers while simultaneously improving the work for our clients.
• A Consistent Quality Check: Having many eyes on one piece of work means issues surface before production, improving quality and reducing design debt. This means a client's project benefits from the entire UX team's perspective.

Our golden rule for giving a design critique remains simple: “Critique, explain, propose.” It’s how we stay grounded, theoretical, and solution-oriented at once.

Integrating Critiques into the Workflow

When the critique ends, the feedback doesn't vanish, it's immediately actionable:

• For open tickets: The designer integrates the insights into the next iteration of the work.
• For closed work: We record suggestions for future reference and share them with the client if relevant.

Every session becomes part of our collective learning system, building a repository of UX design best practices.

More Than a Routine: Our Ritual of Learning

For us, design critiques are not mere meetings; they are a ritual of learning. They remind us that good design doesn't happen in isolation, and that growth comes from openness, respect, and shared curiosity.

When asked how Kaizen’s UX team achieves consistent quality, we point to this practice: a warm group of people, united by listening deeply, questioning respectfully, and building better designs together.

‍