Generating an anime-style character is one thing. Getting their facial expressions right is another thing.

You see, AI image generators have become powerful enough to create whatever image we can think of with just a single prompt. But one thing many image models still struggle with is generating the correct facial expressions of a character.

Ask for “angry,” and you often get the same blank face with slightly lowered eyebrows. Ask for six emotions and two of them are likely to come out looking like twins.

That’s what a character expression sheet is for.

It’s a single reference that shows how one character looks across different emotions, and it’s something you’ll keep coming back to if you’re making a manga, a visual novel, or a storybook.

In this guide, I experimented with PixAI to create a facial expression sheet of a character.

There are two ways to do this.

1. You can generate all the expressions on one sheet in a single run
2. You can create them one expression at a time from the same reference image

I tried both with the same character and the same six emotions, and then I tested what happens when one of the faces needs fixing.

If you want to know where I landed before reading the details, the sheet gave me livelier, more expressive faces for a fraction of the credits. Separate images are the better pick when you need individual files you can fix one at a time, but you’ll have to push the prompts harder to get strong emotions out of them.

I ran these tests on November 12, using Tsubaki.3 at XL resolution with High Priority mode on. At those settings, every generation cost 5,300 credits, whether it was a full sheet or a single face.

Let me share the results.

Start by generating a character in PixAI

Both methods depend on one thing, which is a clear reference image of your character. If the reference is messy, every expression you make from it will be messy too.

So before thinking about emotions, I made a neutral portrait. Head over to PixAI, open the Generate page, and pick Tsubaki.3 from Quick Select. It’s their current flagship model, and it’s the one that can take a reference image and follow editing instructions written in plain English.

Here’s the prompt I used for my character:

Anime-style portrait of a girl, a 20-year-old woman with a short teal bob cut, straight bangs, large amber eyes, and a small mole under her left eye. She wears a yellow star-shaped hair clip on the right side of her hair and a plain cream hoodie. Front-facing view from the chest up, neutral expression with a relaxed, closed mouth, eyebrows fully visible under the bangs. Plain light gray background. Clear facial features

A few things in that prompt are there on purpose.

The face is front-facing, and the eyes, eyebrows, and mouth are all fully visible. Those three are the parts that move when an emotion changes, so the model needs to see them clearly in the reference.

The character has two details that are easy to check at a glance: the star hair clip and the mole under her left eye. I call these anchor details. If the clip changes shape or the mole disappears in one of the expressions, I know right away that the character drifted.

Before moving on, write down what should never change. For this example, that’s the teal bob, amber eyes, the mole, the star clip, and the cream hoodie. Everything else on her face is allowed to move.

If you already have a character you like, you can skip the generation and upload your own image as the reference instead.

Make your first expression in PixAI

Before going for all six faces, I’d recommend trying just one. It’s the quickest way to see how Tsubaki.3 handles your character, and it only costs a single generation.

I started with happy because it’s the easiest emotion to judge at a glance.

1. Open the Generate page and pick Tsubaki.3 from Quick Select.
2. Attach your neutral portrait as the reference image. Once it’s attached, you can call it @image1 in the prompt.
3. Turn off Prompt Helper so the model follows your wording exactly.
4. Set the resolution to XL. I left High Priority on, which gets your image back faster but costs more credits. You can turn it off if you don’t mind waiting in the standard queue.
5. Paste the prompt below and hit Generate.

Prompt: Change only the facial expression of the @image1 character. Keep the face shape, teal bob cut, amber eyes, mole under the left eye, yellow star hair clip, cream hoodie, pose, framing, art style, and light gray background exactly the same. New expression: a big open-mouth smile showing her upper teeth, cheeks raised, eyes slightly squinted into curved shapes, eyebrows relaxed and lifted.

I got the result on the first attempt, and it cost 5,300 credits. The hair clip, the mole, and the hoodie all stayed the same, and only her face changed. The smile is on the gentle side, which I’ll talk more about in Method 2.

To try this with your own character, swap two things in the prompt. Replace the features in the keep list with your character’s details, and replace the last sentence with the emotion you want, written as what the eyebrows, eyes, and mouth are doing.

If you have an OC of your own, upload them to PixAI and try one new expression before reading further. A new account comes with enough starter credits to cover this first test.

Method 1: Generate all six expressions on one sheet

The first method is the fast one. You attach the reference image, describe the whole sheet in one prompt, and get all six faces back in a single image.

Attach the character’s portrait as a reference image so you can call it @image1 in the prompt. I also turned off Prompt Helper for this, because I wanted the model to follow my wording exactly instead of a rewritten version of it.

This is what your PixAI image generation dashboard is going to look like:

Here’s the prompt:

Create a character expression sheet of the @image1 character. Arrange six head-and-shoulders portraits in a clean grid with 2 rows and 3 columns, each in its own equal-sized cell with a thin white gap between cells. Keep the same face shape, teal bob cut, amber eyes, mole under the left eye, yellow star hair clip, and cream hoodie in every cell. Same front-facing framing, same art style, same plain light gray background. No text or labels.

Row 1: neutral with a relaxed closed mouth; happy with a wide open smile, raised cheeks, and slightly squinted eyes; angry with eyebrows pulled down and together, narrowed eyes, and clenched teeth.

Row 2: sad with inner eyebrows raised, glossy downcast eyes, and a small frown; surprised with eyebrows raised high, wide round eyes, and a small open mouth; shy with eyes looking away to the side, a strong blush across the cheeks, and a small wavy closed mouth.

Looking at the final output, I have to say, the results are awesome. I love how animated the expressions turned out. They still resemble the original character, yet each varied face successfully captures the exact emotion I was aiming for.

It also came out right on the first attempt, so the whole sheet cost me 5,300 credits. That’s six faces for the price of one image.

The prompt has four parts, and you can reuse the same order for your own character.

1. It starts with what to make and how the grid is laid out.
2. Then it lists the features that must stay the same.
3. Then the framing and background.
4. The emotions come last, grouped by row.

Notice that I didn’t just write “happy, angry, sad.”

Each emotion comes with what the eyebrows, eyes, and mouth are doing. This matters more than anything else in the prompt. A single emotion word leaves the model to guess, and its guess is usually a small change to the mouth while the rest of the face stays frozen.

I also asked for no text. Generated labels can come out misspelled or land on the wrong cell, so it’s easier to add them yourself afterward in any image editor. That’s how I added the labels on the sheet above.

What to check on the sheet

Once the sheet is done, go through it cell by cell.

• Count the emotions first. All six should be there, and each one should appear only once.
• Look for twins. Happy and shy are the pair most likely to end up looking alike, because both involve a smile and a blush. Sad and neutral are the other pair to watch.
• Check the anchor details in every cell. For my example, that means the mole is still under the left eye and the star clip is still on the same side.
• Check the framing. Every head should be about the same size and none of them should be cut off at the edge of a cell.

What I like about this method is that you see the character’s whole emotional range in one image. It’s the quickest way to find out if a design can carry different moods before you commit to it.

And if you want to go beyond expressions and build a full reference package with a turnaround, outfit details, and a color palette, PixAI has a guide to OC and VTuber character sheets that takes the same idea further.

Method 2: Edit one expression at a time

The second method takes a bit longer, but you get more control over each face.

Instead of asking for a grid, you go back to the original neutral portrait and ask Tsubaki.3 to change only the expression. You do this once per emotion, and each result is its own full-size image. If you followed the walkthrough above, you’ve already done the first one.

The important rule is to always start from the original reference. Don’t edit the happy image to make the angry one. Every edit moves the character a tiny bit away from the original, and if you chain edits together, those small changes pile up.

The neutral portrait already counts as your neutral expression, so you only need five edits.

I used one shared instruction for all of them and only swapped the last sentence:

Prompt: Change only the facial expression of the @image1 character. Keep the face shape, teal bob cut, amber eyes, mole under the left eye, yellow star hair clip, cream hoodie, pose, framing, art style, and light gray background exactly the same. New expression: [EXPRESSION]

And here’s what I put in place of [EXPRESSION] for each one:

• Happy: a big open-mouth smile showing her upper teeth, cheeks raised, eyes slightly squinted into curved shapes, eyebrows relaxed and lifted.
• Angry: eyebrows pulled down and together, narrowed eyes glaring straight at the viewer, clenched teeth, a tense jaw.
• Sad: inner ends of the eyebrows raised, glossy eyes looking down with tears starting to form, lips pressed into a small trembling frown.
• Surprised: eyebrows raised high above the bangs line, eyes wide open and round with small pupils, mouth open in a small “o” shape.
• Shy: head tilted slightly down, eyes looking away to the lower right, a heavy pink blush across both cheeks and the nose, a small wavy closed mouth.

Each edit worked on the first attempt at 5,300 credits, so the five edits came to 26,500 credits.

To use this for your own character, replace the character’s features in the keep list with your own, and leave the rest as it is.

The fun part about this method is that you can control how strong an emotion is. “Angry” could mean mildly annoyed or completely furious, and on a sheet you mostly get whatever the model decides.

Here, you can write “slightly annoyed, one eyebrow lowered, mouth pulled to one side” and get that specific version.

You also end up with six separate files at the same size and the same framing. If you plan to use the faces in a visual novel or as reaction images, that’s the format you need anyway.

However, looking at the individual results and comparing them back to the single expression sheet above, I found the level of expression here to be way lower. There’s barely any noticeable change on her face.

Yes, you can technically detect the intended emotion, but the variation is minimal. I really wish there had been more dramatic head tilting, skin color changes, eyebrow movement, and overall facial dynamism to give each portrait more life.

What happens when one expression needs fixing?

No matter which method you use, one face will probably come out wrong. The shy one could look too much like the happy one, or the angry one could look more bored than angry. How easy it is to fix that one face is the biggest difference between the two methods.

On a sheet, all six faces are part of the same image. You can’t just regenerate one of them.

You have two options.

1. The first is to run the whole sheet again with a better description for the weak emotion. That works, but you’re also rolling the dice on the five faces that were already fine.
2. The second option is to edit only the bad cell. The model only repaints what’s inside a mask and leaves everything else alone.

I went with the second option and used it on the shy face in the bottom-right cell. Here’s how:

1. Upload the finished sheet to PixAI’s image editor. Uploading an image puts you straight into edit mode.
2. Switch to mask mode and paint over the shy face. Paint the mask a little larger than the face and turn on feathering so the new face blends into the cell.
3. Type a prompt that describes only the new expression, then click Generate.

This is the prompt I used:

Eyes looking away to the lower right

After the fix, check the cells next to it and make sure the mole and the star clip are still in the right place on the repainted face.

With separate images, the fix is simpler. You go back to the original reference, rewrite the expression, and generate that one image again. The other five files aren’t touched at all.

Since the shy face from Method 2 was one of the flattest results, I regenerated it using the same shy description from the sheet fix above.

Here’s the before-and-after edit of the shy expression:

One more thing about cropping

You might be tempted to generate the sheet and then crop the six faces into separate files. You can do that for quick previews, but keep your expectations low.

Each cropped face is only a fraction of the sheet’s resolution. The crops won’t line up perfectly with each other, and you won’t get transparent backgrounds.

If you need separate images that are ready to use, make them separately.

Which workflow should you choose?

Here’s how the two methods compared in my test. Both used the same neutral reference, which cost one 5,300-credit generation and isn’t counted in the totals below.

The sheet wins on cost and, in my test, on how expressive the faces looked. The individual images cost about six times more, but you get files you can fix and use one by one.

Keep in mind that neither method gives you transparent backgrounds or sprites that a visual novel engine can use right away. You’ll still need to remove the background and line the images up yourself.

If you’re new to PixAI, you can sign up through this link to get 50,000 extra credits. You don’t need the bonus to get started, though. Your first expression costs 5,300 credits at the settings I used, and the starter credits on a new account already cover that.

Frequently asked questions

How do I make an expression sheet from an existing character?

Attach a clear, front-facing image of your character as a reference in Tsubaki.3, then describe the grid and each emotion in one prompt. List the features that must stay the same, like hair, eye color, and accessories, so the model keeps them in every cell.

Why do several expressions look almost identical?

Usually because the prompt only names the emotions. Words like “happy” and “shy” leave the model to guess, and it often changes just the mouth. Describe what the eyebrows, eyes, and mouth are doing for each emotion, and the faces will be much easier to tell apart.

How do I fix only one expression?

On a sheet, open it in PixAI’s image editor, mask the face you want to redo, and describe the new expression. For separate images, go back to the original reference and generate that one expression again with a more specific description.

Final Thoughts

If you’re making a character for a storybook, a manga, an anime series, or anything else where the same face shows up again and again, an expression sheet is one of the most useful things you can prepare.

It’s your proof that the character still looks like themselves when they’re laughing, crying, or furious, and it saves you from finding out halfway through a project that your hero has no convincing sad face.

Personally, I’d make the full sheet first to see what the character can do, and then switch to one expression at a time for anything I actually plan to use.

Both methods have their own place. A full expression sheet is great for exploring your character’s wide range of emotions, while separate images give you more control and suit individual assets better.

Whichever you choose, start with a clear and accurate reference and describe each expression in detail. Tell the model what the eyebrows, eyes, and mouth are doing instead of just naming the emotion.

If you want to take your character further, I also wrote a guide on how to make manga pages with Tsubaki.3, and an expression sheet like this one is a good thing to have ready before you start on panels.

Let me know your thoughts in the comments!

This story is published under the Generative AI publication. Connect with us on LinkedIn and follow Zeniteq to stay in the loop with the latest AI stories. Let’s shape the future of AI together!

AI Character Expression Sheets: One Sheet or One Expression at a Time? was originally published in Generative AI on Medium, where people are continuing the conversation by highlighting and responding to this story.

As a dev and solopreneur, I make presentations regularly for client updates, content strategy pitches, and monthly growth reports. These reports usually start as a messy Google Doc and end up in Google Slides or PowerPoint. Before all these AI tools came out and became popular, I often did things manually.

Today, AI presentation generators like Plus AI and Gamma App make my life easier. I just dump the data or link, and the agent takes care of all the heavy lifting.

But which tool is better?

In this article, I’ll explain how each tool works, what it’s like to use them day to day, and which one I’d recommend for different kinds of work.

Let’s get started.

Plus AI vs Gamma: What’s the Difference?

The biggest difference is where each tool lives.

Plus AI is an add-on that runs inside PowerPoint and Google Slides. You open a regular deck, click the Plus AI panel on the side, and it builds or edits slides right there in your file.

You don’t need to keep on switching tabs when working with a presentation. This is perhaps the biggest reason why you should pick it. The dashboard is already familiar, so there is almost no learning curve at all.

Gamma is its own web app. You create, edit, and present everything inside the Gamma website, then share a link or export to PowerPoint, PDF, or Google Slides when you need a file.

So, choose Plus AI if your team works in PowerPoint or Google Slides and needs decks that stay fully editable in those apps.

You can switch to Gamma if you prefer a more ChatGPT-style interface and you want the output to be in HTML format.

Plus AI: Features and Highlights

Plus AI was built by a team of former management consultants, designers, and engineers, and you can tell. The whole tool is designed around the way people already make work presentations.

You can install it by adding it as an add-on in Google Slides.

After you install the add-on, a side panel opens next to your slides. When you create a new presentation, just open the Extensions tab, then under the Plus AI for Google Slides menu, select New presentation with Plus AI.

In the presentation generator dashboard, you will see a bunch of parameters. You can start from scratch or choose from templates.

For example, you could ask for a presentation of a monthly financial report. Click on the “use a prompt” button to add the financial data. You can also upload a document if it’s in PDF or Doc format.

Here’s the full prompt:

MONTHLY FINANCIAL REPORT – March 2026
Company: Horizon Tech Solutions
Reporting Period: March 2026
Currency: USD
Financial Overview
The company recorded a net profit this month, supported by strong revenue growth and controlled operating expenses. Overall financial performance remained stable and aligned with quarterly targets.
Income Summary
Total revenue for the month was $1,480,000, representing an 11% increase compared to the previous month. Cost of goods sold totaled $620,000, resulting in a gross profit of $860,000 and a gross margin of 58%.
Operating Expenses
Operating expenses amounted to $610,000.
Key expense drivers included employee salaries, cloud infrastructure costs, and marketing spend tied to customer acquisition campaigns.
Net Result
After operating expenses, the company achieved an operating income of $250,000.
Taxes and miscellaneous expenses totaled $70,000, leading to a net income of $180,000 for the month.
Cash Flow
Operating cash flow remained positive at $210,000.
Capital expenditures were limited to routine software and hardware upgrades, ensuring healthy cash reserves.
Balance Sheet Highlights
 • Cash and cash equivalents: $2.3M
 • Accounts receivable: $420,000
 • Total assets: $4.8M
 • Total liabilities: $2.1M
Key Financial Insights
 • Profit margins improved due to better cost control
 • Marketing spend showed a positive return on investment
 • Cash position remains strong, supporting near-term growth initiatives
Outlook for Next Month
Revenue is expected to grow moderately, with expenses remaining stable. Focus will remain on maintaining profitability while supporting strategic investments.

Adjust some parameters to customize the output. You can change the length, the design of the template, and the writing tone. Click on the generate button and wait for the final deck to be displayed.

Here’s what the sample output looks like:

Before it generates the final slides it creates an outline for you. This is a crucial step because it allows you to see the structure of the presentation. You can edit the headers and rearrange the flow to make sure it tells the right story. Once you approve the outline the AI builds the slides right on your existing canvas.

Here’s what the final slides look like:

Because Plus AI works natively inside Google Slides and PowerPoint the final output is just a standard presentation file. Every text box and image is fully editable. You can share the file with a colleague and they can edit it even if they do not have Plus AI installed.

Plus builds its own PPTX files with an in-house Open XML renderer, so when you open the deck in PowerPoint, nothing looks broken or flattened into an image.

On the Team plan, you can add your logo, colors, and fonts. Enterprise customers can go further and import their company’s actual slide masters, so the AI builds slides using the same templates the design team already approved.

Gamma: Features and Highlights

Gamma takes a different approach. Instead of classic slides, it builds presentations out of cards, which work like flexible slides that stretch to fit their content. Gamma says people have used it to create more than 250 million presentations, websites, social posts, and documents.

Getting started takes about a minute. You type a prompt, paste an outline, or upload a Word doc, PDF, or Google Doc. Then you pick a theme, and Gamma writes the copy, chooses layouts, and adds images automatically.

The editor feels more like Notion than PowerPoint. You add content in blocks, drag them around, and ask the built-in AI assistant to rewrite a card, change its layout, or generate a new image. Switching the whole deck to a different theme takes one click.

When you’re done, you can present straight from Gamma, share a live link, or export to PowerPoint, PDF, PNG, or Google Slides. Gamma can also turn the same content into a website, a document, or social media graphics, which Plus AI doesn’t try to do.

Higher plans add custom branding, detailed analytics on who viewed your deck, custom domains, and API access.

Plus AI vs Gamma

Here’s a quick comparison of the two platforms:

Feature lists only tell you so much. What matters in practice is how each tool feels when you’re actually building a deck under a deadline.

Generating a Deck From a Prompt

Gamma is the faster of the two. You type a prompt, pick a theme, and in under a minute you have a full deck with photos, icons, and a different layout on almost every card.

The first time I tried it, I was honestly impressed by how finished it looked.

Here’s an example:

The AI generates content in fluid blocks that auto-resize to fit the text. You don’t have to worry about font sizes or text overflowing a box because the “Smart Slides” handle all of that for you.

The catch is the writing. Gamma tends to be wordy, and since cards stretch to fit their content, it doesn’t force itself to cut anything. Some cards end up with two or three paragraphs where a real slide would have a headline and a few short lines.

It can also fill gaps with numbers you never gave it, so you have to read every card before you present.

Plus AI takes a bit longer, usually a minute or two. Before building anything, it shows you an outline of every slide, and you can reorder, rename, or delete slides at that stage. I like this step a lot, because it’s much easier to fix the structure of a deck before the slides exist.

The finished deck looks more corporate. Plus uses its own designer templates with consistent fonts, tidy spacing, and icons next to the bullet points. The slides are tighter than Gamma’s, with short headlines and three or four points each. They can feel a little plain, especially if you don’t turn on image generation.

Editing After the First Draft

No AI tool gives you a perfect deck on the first try, so editing is where you’ll spend most of your time.

Plus AI’s Remix and Rewrite tools are the best part of the product for me. You select one slide, pick a new layout, and Plus rebuilds it in a few seconds while leaving the rest of your deck alone.

If a slide is just a wall of text, Remix can turn it into a timeline or a set of columns with icons, and Rewrite can tighten the wording without touching the layout.

Gamma’s AI assistant is more flexible. You can ask it for almost anything in plain English, like “make this more concise” or “turn this into a timeline,” and it usually gets it right. Changing the look of the entire deck with one click is also something PowerPoint can’t match.

Where Gamma gets frustrating is fine control. Its block-based editor doesn’t let you drag elements anywhere you want the way PowerPoint does. If you want to nudge one icon slightly to the left or shrink a single image, you’ll often end up trying different layout presets until one is close enough.

Plus AI vs Gamma: Feature-by-Feature Comparison

Design Quality

First impressions count, especially if you’re presenting to clients or investors.

• Plus AI: The designer templates are clean and professional, with consistent fonts and spacing. They look like something a consulting firm would use. They’re also a little safe, and without images, some slides feel plain.
• Gamma: Gamma’s themes are modern and bold, and it adds images and varied layouts without being asked. Most people would look at a Gamma deck and assume a designer made it.

Winner: Gamma. Its first drafts look noticeably better with no extra effort from you.

Editability and File Compatibility

This category decides what happens after the AI is done, when you or your coworkers need to keep working on the deck.

• Plus AI: Everything is native to PowerPoint and Google Slides. Charts are real charts, text boxes are real text boxes, and your deck works with any template or add-on you already use.
• Gamma: You can export to PowerPoint and Google Slides, but the export is a conversion from Gamma’s card format. Text boxes can shift, fonts can get replaced, and long cards sometimes split in odd places. It’s fine if you present from Gamma, but it adds cleanup if your team works in PowerPoint.

Winner: Plus AI. If your deck needs to live in PowerPoint or Google Slides, working inside the file itself saves a lot of fixing later.

AI Editing Tools

Generating a deck is only half the job. Most of my time goes into fixing slides after the first draft.

• Plus AI: Remix and Rewrite are fast and precise. You pick exactly which slide or text to change, and Plus leaves the rest alone. Custom instructions and saved presets (on the Team plan) also help if you make similar decks every week.
• Gamma: The AI assistant handles almost any request in plain English, and changing the entire theme takes one click. Fine control over positioning is harder, though.

Winner: Tie. Plus AI is better for precise edits, and Gamma is better for big changes across the whole deck.

Branding and Templates

If you work for a company with brand guidelines, this might be the most important category for you.

• Plus AI: The Team plan lets you set your logo, colors, and fonts. On Enterprise, Plus can build slides directly from your company’s own slide masters and asset libraries.
• Gamma: Pro users can create a custom branded theme with their colors, fonts, and logo. It works well for Gamma decks, but it’s a Gamma theme, separate from your company’s official PowerPoint template.

Winner: Plus AI. Being able to use your company’s real templates saves a lot of back-and-forth with the design team.

How to Make Your Choice

Overall, I’d pick Plus AI for most work presentations, because most work decks end up in PowerPoint or Google Slides anyway. Gamma is the better choice when looks and speed matter most and you control how the deck gets presented.

Plus AI Is Better For:

• Consultants and agencies: Client decks need to open cleanly in PowerPoint and match the client’s template.
• Corporate teams: The deck gets passed between several people who all edit it in Google Slides or PowerPoint.
• Data-heavy updates: You need charts your team can click into and update next quarter.

Gamma Is Better For:

• Founders and freelancers: You want a sharp pitch or proposal fast, and you’re fine sharing it as a link.
• Content creators and educators: You want the same material as slides, a web page, and social posts.
• Occasional users: You make a few decks a month and want a free or low-cost option.

Final Thoughts

Alright, I’ve just laid out the differences between Plus AI and Gamma and shared the key points you should know when choosing between the two.

I’ve been using both tools for over a year now, so you can trust me in this review.

For my own personal projects and client work, I prefer Plus AI. I’ve always been a PPT and Google Slides user since I was in college, so having an agent built into these platforms is a huge help and time saver for me.

Its Remix and Rewrite tools let me fix one slide without touching the rest, and I never have to rebuild a deck after exporting it.

In times when I need graphic heavy presentations, I switch to Gamma. The agentic interface also helps me easily perform deep research and link to some sort of database when dealing with reports.

If you’re deciding between them, think about three things.

1. First, where will the deck live after you’re done: in PowerPoint and Google Slides, or as a shared link?
2. Second, how much do you care about the first draft looking polished versus being easy to edit?
3. Third, how often will you use it? If it’s just a few decks a month, Gamma’s free plan might be all you need.

It’s also worth saying how much these tools have changed the way I work. A year ago, turning a 10-page report into a clean deck took me hours of work. Now I can get a really good output in a few minutes and spend my time on the parts that actually need a human, like the story and the numbers.

What do you think? Have you tried Plus AI or Gamma, or do you use a different AI presentation tool?

Let me know your thoughts in the comments.

This story is published under the Generative AI publication. Connect with us on LinkedIn and follow Zeniteq to stay in the loop with the latest AI stories. Let’s shape the future of AI together!

Plus AI vs Gamma AI: Which Tool Is Better for AI Presentations? was originally published in Generative AI on Medium, where people are continuing the conversation by highlighting and responding to this story.

An AI coding agent can generate a screen in SwiftUI, implement a repository, create a ViewModel, or integrate an API in seconds. The resulting code may pass compilation but be completely wrong for your project.

It might introduce a new networking abstraction when the application already has one. It might put business logic inside a View, ignore an existing dependency injection mechanism, use an outdated API, or introduce a third-party dependency for something the project already implements.

This is not necessarily an issue with the model intelligence. This can be attributed to the lack of context, constraints, and verification.

A coding agent cannot tell from the prompt why you need a certain architecture, which abstractions are required, which APIs are forbidden, and which style of coding you and your team prefer.

You can mention all that in every prompt, but this won’t be a scalable solution.

Harness engineering addresses this problem by engineering the environment around the coding agent so that it consistently produces code aligned with the project’s engineering standards.

Mitchell Hashimoto discussed this approach in his February 2026 article, My AI Adoption Journey. His practical recommendation is straightforward: when an agent makes a recurring mistake, improve its instructions or build a tool that prevents the mistake from happening again.

For Swift development, this opens up an interesting engineering discipline: building a coding harness that understands your repository, enforces your architecture, and verifies generated code.

1. Give the agent persistent knowledge of the repository

The first problem is context.

The coding agent can review the source files, but reviewing the files does not mean that the agent understands the engineering choices made while creating them.

Take, for example, an iOS app that uses:

• SwiftUI for the user interface.
• MVVM architecture with a separate domain layer.
• Repository pattern for accessing data.
• Protocol-based dependency injection.
• Swift Concurrency for asynchronous work.
• SwiftData for local persistence.

Without instructions, the coding agent may use another design pattern while building the feature. The solution is the file with instructions at the repository level, usually AGENTS.md or any other extension allowed by your coding agent.

It should explain how the project is expected to be developed.

For example:

# Swift Engineering Guidelines

## Architecture
- Follow the existing architectural boundaries.
- Views must not access repositories directly.
- Business logic belongs in domain use cases.
- ViewModels coordinate presentation state.
- Repositories own data access.
- Do not introduce new architectural patterns
  without explicit approval.
## Swift
- Follow Swift API Design Guidelines.
- Prefer value types where appropriate.
- Use protocols at meaningful abstraction boundaries.
- Avoid force unwrapping.
- Handle errors explicitly.
- Respect Sendable and actor isolation requirements.
- Never use Task.detached without justification.
## SwiftUI
- Keep View bodies focused on composition.
- Extract reusable components when appropriate.
- Avoid business logic inside View implementations.
- Follow existing navigation and state-management patterns.
## Dependencies
- Prefer existing project dependencies.
- Do not introduce third-party packages
  without approval.
## Before completing a task
- Build the affected target.
- Run relevant unit tests.
- Run SwiftLint and formatting checks.
- Verify architectural constraints.
- Report any checks that could not be executed.

The key here is that the rules should be relevant.

Do not write a 500-line document with generic Swift guidelines. Document decisions specific to your repository.

For example, if your project uses a custom AppRouter, explicitly tell the agent to use it instead of introducing NavigationStack independently throughout the application.

Repository guidelines must also inform the agent on where they can find more comprehensive documentation, how to execute the build, and which files define the project’s architectural conventions.

2. Turn engineering principles into enforceable rules

Instruction sets the expectations, but does not ensure compliance.

The agent may read a rule that says the presentation modules must not be dependent on the data modules and still create this dependency.

This is where harness engineering needs to move beyond prompting.

Consider three categories of engineering standards.

Coding standards: Naming, formatting, access control, error handling, documentation, and Swift conventions.

Tools such as SwiftLint and Apple’s swift-format can enforce many of these automatically.

Architectural standards: These cover module dependencies, layering, dependency injection, separation of concerns, and allowed framework usage.

For example:

• SwiftUI presentation modules cannot import database implementation modules.
• ViewModels cannot instantiate concrete repositories.
• Networking implementations cannot be accessed directly from presentation code.
• Domain models cannot depend on SwiftUI.

Some constraints can be checked using SwiftLint custom rules, SwiftSyntax-based checks, or dedicated architecture tests.

Design principles: Avoid unnecessary abstractions, keep types simple and focused, make good use of protocol abstractions and reuse existing components.

Whilst not everything can be enforced using static analysis, by providing concrete examples and enforcing rules that can be done using automation, we are trying to make it as deterministic as possible.

The objective is to move rules out of the agent’s memory and into the development environment.

3. Give the agent tools to understand the Xcode project

The coding agent requires more than mere access to the source code files.

It also requires knowledge of the project structure, build targets, build settings, dependencies, and test frameworks.

For an Xcode project, this means providing reliable access to:

• Project and workspace structure.
• Build schemes and destinations.
• Swift Package dependencies.
• Build settings.
• Test targets.
• Compiler diagnostics.
• Test results.

Apple provides command-line tools such as xcodebuild, simctl, and xcresulttool for automating these workflows.

A useful harness should wrap commonly required operations into predictable commands.

For example:

./scripts/agent/project-info.sh

./scripts/agent/build.sh \
    --scheme MyApp

./scripts/agent/test.sh \
    --scheme MyApp \
    --filter UserRepositoryTests

./scripts/agent/lint.sh

./scripts/agent/architecture-check.sh

These would be project-specific scripts, rather than built-in Xcode commands.

This allows the agent to avoid constantly figuring out how your team builds and tests the application from scratch.

The project-info script can provide information about available schemes, targets, deployment settings, and dependencies. The build script can select the correct simulator destination and provide compiler diagnostics in a consistent manner.

This also avoids any errors arising from agents creating their own commands or choosing incorrect build configurations.

The tools should be documented in AGENTS.md so the agent can know when and how to run them.

4. Make verification part of code generation

This is arguably the most important stage in the harness.

The coding agent must not treat a job as completed simply because it has generated the required files. It should verify that the implementation satisfies the project’s requirements.

Here is how a verification pipeline can work for Swift development:

Every phase addresses a specific question.

• Formatting inspects code consistency.
• Linting identifies prohibited patterns and coding-standard violations.
• Building discovers compilation problems, wrong API calls, and type errors.
• Unit tests validate business logic.
• Integration tests verify interactions between components.
• Architecture checks detect forbidden dependencies and structural violations.
• Review checks whether the implementation actually matches the requested behavior.

For example, a feature may pass a compilation test by having a ViewModel that directly accesses the database implementation. This will not have been picked up by the compiler, but should be picked up by a specific architecture test.

SwiftLint will also be able to pick up on issues we have set up to fail on but cannot tell us if something is overcomplicated or if the agent has duplicated an existing business rule.

Different verification mechanisms must cover different classes of mistakes. A good harness will make these easy to run and give the agent helpful feedback on why they have failed.

Apple provides testing support within Xcode, which allows for Swift Testing, XCTest, and XCUIAutomation for unit and integration tests and UI tests.

5. Build a feedback loop from recurring mistakes

What makes harness engineering valuable is the fact that it becomes better with experience.

Suppose an agent keeps on using try! in implementing repositories. The first reaction could be to tell the agent not to do it again. The next time, however, it would make the same mistake.

A better solution is to fix the harness.

1. Add a specific error-handling rule to your repository instructions.
2. Create a lint rule/static check where possible.
3. Add a relevant test if the behavior affects application correctness.
4. Have your verification script run this.
5. Update your documentation to describe how the agent should act.

This means that your next agent session will have guidance and a mechanism to detect this violation. This can be applied to architectural errors too.

If agents keep creating duplicate network clients, document the network entry point and add validation that stops unauthorized implementations.

If agents are using outdated APIs, add a quick reference guide to help them migrate and add validation if possible.

If agents are continually editing generated files, clearly mark the generated folders in the project and add protections to stop them editing.

This creates a continuous improvement loop:

The important distinction is that you’re not accumulating prompt instructions indefinitely. You’re converting recurring failures into permanent engineering controls.

6. What a practical Swift coding harness looks like

A repository can organize these components without depending on a particular coding agent.

For example:

MyApplication/
│
├── AGENTS.md
│
├── .agent/
│   ├── instructions/
│   │   ├── swift.md
│   │   ├── swiftui.md
│   │   ├── architecture.md
│   │   └── testing.md
│   │
│   ├── skills/
│   │   ├── implement-feature/
│   │   ├── add-unit-tests/
│   │   └── review-swift-code/
│   │
│   └── references/
│       ├── architecture.md
│       └── dependency-rules.md
│
├── scripts/
│   └── agent/
│       ├── project-info.sh
│       ├── build.sh
│       ├── test.sh
│       ├── lint.sh
│       └── architecture-check.sh
│
├── Sources/
├── Tests/
└── MyApplication.xcodeproj

This is an illustrative structure. The actual instructions and skills should be structured according to your chosen coding agent.

The responsibilities are deliberately separated:

• AGENTS.md establishes repository-wide expectations.
• Instructions describe language, framework, and architecture rules.
• Skills provide repeatable workflows for specific engineering tasks.
• References explain decisions that require more context.
• Scripts provide deterministic development and verification capabilities.
• Tests enforce requirements independently of the agent.

A feature implementation skill, for example, could instruct the agent to inspect existing implementations, identify the correct architectural layer, prepare a change plan, implement the feature, add tests, and execute the verification pipeline.

The workflow should also require the agent to report what changed, which checks passed, and which checks remain incomplete.

7. Don’t confuse more instructions with a better harness

There is a temptation to address every agent mistake by putting yet another paragraph into AGENTS.md.

Eventually, this method will work against you.

Instructive language will become repetitive, self-contradictory, and hard to manage. Even worse, the agent will be bombarded with context until it is difficult to understand the project-specific instructions.

Use the right mechanism for each problem.

Not every problem needs a custom tool. Not every coding standard needs another instruction file.

The goal is to make the correct engineering path easier for the agent to discover and follow than the incorrect one.

The harness should become part of the engineering system

A good Swift coding harness will change how teams approach AI-assisted development.

Decisions around your architecture will be captured in your repo, instead of developers having to explain them every time.

Rules will be captured and checked automatically, instead of agents having to remember them.

Code will be created, tested, and validated, instead of just being trusted because it looks correct.

If the agent is making the same mistake regularly, this will improve the environment for all future tasks.

The real measure of harness engineering isn’t how detailed your instructions are or how many tools your agent can access. It’s whether the same class of mistake becomes progressively harder to introduce.

That’s how an AI coding agent moves from generating plausible Swift code to contributing code that actually belongs in your application.

Sources

• My AI Adoption Journey — Mitchell Hashimoto. The original discussion of improving agent instructions and verification tools.
• Swift API Design Guidelines — Swift.org. Official conventions for designing clear Swift APIs.
• Xcode Command-Line Tool Reference — Apple. Xcode build, simulator, and result inspection tooling.
• Testing in Xcode — Apple. Swift Testing, XCTest, and UI testing guidance.
• swift-format Configuration — Swift. Configurable Swift formatting and linting.

This story is published under the Generative AI publication. Connect with us on LinkedIn and follow Zeniteq to stay in the loop with the latest AI stories. Let’s shape the future of AI together!

Harness Engineering for Swift: Making AI Coding Agents Follow Your Engineering Standards was originally published in Generative AI on Medium, where people are continuing the conversation by highlighting and responding to this story.

Whilst an AI coding agent can produce a Maestro YAML flow in seconds, this does not necessarily mean that it will be a good test.

It may guess at accessibility identifiers, get confused with the navigation of the application, interact with the wrong element or just assert that the screen is displayed without checking if the business process has been successful. The YAML may be syntactically correct but offer little testing value.

The typical solution to this would be to improve the prompt given to the agent. Provide more instructions, a second screenshot, explain what the flow should do and ask the agent to try again.

That approach has a ceiling.

The issue isn’t necessarily the model's ability to create YAML; the agent simply does not have the environment and feedback to understand how the application works, investigate, inspect its behavior, and validate its outputs.

This is where harness engineering comes into play.

Mitchell Hashimoto introduced the term harness engineering in his February 5, 2026 essay, My AI Adoption Journey. His underlying idea is particularly useful for software engineering: when an agent repeatedly makes a mistake, don’t just correct that output. Engineer a mechanism that prevents the same mistake from recurring.

An elegant way to represent this would be: Agent = Model + Harness

The model gives us reasoning and flow generation ability. The harness gives us all that makes reasoning and flow generation work effectively in a specific engineering context.

When it comes to automating mobile UIs, this would mean creating an engineering context that would allow an agent to analyze an app, discover its UI, generate Maestro flows, execute them on a real build, analyze any failures, and improve its design based on hard facts.

The goal isn’t to make an agent better at writing YAML. It’s to make the agent better at engineering tests.

First, understand what the agent needs to do

Consider a requirement:

Verify that a user can sign in, search for a product, add it to the basket, and see the updated basket total.

A basic AI workflow could be:

1. Give the requirement to an LLM.
2. Ask it to create a Maestro flow.
3. Save the YAML file.
4. Run the test.

This assumes that the model understands the application structure, test data, correct accessibility identifiers, and expected behaviour of every screen.

However, this is rarely the case in an existing application.

A capable test-generation agent needs to perform several distinct activities:

• Understand the requirement and identify the expected behavior.
• Explore the repository to discover existing test conventions.
• Inspect the application to understand the currently rendered UI.
• Identify appropriate selectors and interaction sequences.
• Generate a Maestro Flow following repository conventions.
• Execute the Flow against the actual application.
• Inspect screenshots, UI hierarchy, and execution logs.
• Correct failures without weakening the original test intent.

These activities require more than a system prompt. They require a coordinated set of guides, tools, data sources, sensors, and execution controls.

1. Guides: Teach the agent how to work in the repository

The first component of the harness is guidance.

You should not have to guess how to conform to the guidelines of the repository each time you create a test.

The root folder should have an AGENTS.md file which explains the structure of the repository, testing guidelines, limitations, and available tools.

For example:

# AGENTS.md

## UI Automation
- Use Maestro for mobile UI automation.
- All new flows belong under .maestro/flows/.
- Reuse existing subflows where appropriate.
- Follow the existing naming and tagging conventions.

## Before Writing Tests
- Read the relevant application feature implementation.
- Inspect existing Maestro flows.
- Inspect the running application before selecting elements.
- Verify selectors using the actual UI hierarchy.
- Identify required test data and application state.

## Selector Strategy
- Prefer stable accessibility identifiers.
- Use visible text when it represents a stable
  user-facing contract.
- Avoid coordinate-based selectors unless
  no reliable semantic selector exists.
- Never invent identifiers.

## Test Quality
- Assert meaningful user-visible outcomes.
- Do not replace assertions with weaker checks
  merely to make a flow pass.
- Do not add arbitrary delays to compensate
  for synchronization problems.
- Keep flows focused on one scenario.

## Validation
- Execute every newly generated flow.
- Inspect failure artifacts before modifying
  a failing test.
- Report tests that could not be executed.

It’s a starting point, not a full harness.

The directions set up expectations, but they can’t provide the agent with anything more than what is available in the repository and the application.

For example, telling the agent to inspect accessibility identifiers is useful only when it has an actual mechanism to retrieve the UI hierarchy.

That’s why directions and tools must be created at the same time.

And I wouldn’t try to include all test conventions into one giant direction file. Keep the repository-level rules small and use a separate skill for Maestro authoring.

A possible structure is:

project/
│
├── AGENTS.md
│
├── .agents/
│   └── skills/
│       └── maestro-test-authoring/
│           └── SKILL.md
│
├── .maestro/
│   ├── config.yaml
│   ├── flows/
│   └── subflows/
│
├── tools/
│   ├── build-app
│   ├── install-app
│   ├── inspect-screen
│   ├── run-maestro
│   └── collect-diagnostics
│
└── docs/
    ├── app-architecture.md
    └── test-data.md

This skill contains the actual steps required to investigate a requirement, explore the screen, select elements, create flows and validate.

The agent will understand the general rules in AGENTS.md and follow these detailed steps when undertaking a Maestro authoring task.

This approach also makes the harness reusable across different coding agents.

2. Context pipelines: Give the agent the right application knowledge

Test generation agents require application context from more than one source.
A screenshot, source code and existing test files are not enough.

The harness should assemble relevant information from:

Application source code: The agent must be able to analyze the implementations of screens, navigation paths, ViewModels, UI state models, and accessibility ids.

This helps it understand the intended application structure and how different screens are connected.

Existing Maestro flows: They show real examples of repository conventions, reusable subflows, selectors, and assertions.
The existing automation becomes very helpful since it shows decisions made by the team.

Runtime application information: The agent must be able to analyze the application when it runs on an emulator, simulator, or device.
At that point, it becomes important to be able to analyze UI hierarchy and take screenshots.

Requirements and test specifications: The agent should receive the expected preconditions, user actions, and postconditions rather than being asked to infer the complete test from a loosely worded feature description.

Test data and environment information: The agent needs to understand which test accounts, backend fixtures, API environments, and configuration parameters are available.

None of the above sources needs to be fed into the context of the model at one time.

Proceed with progressive discovery. Begin with the feature and test structure, followed by retrieving the information on how the screen is implemented and navigated. It is important that the quality of the assembled context takes precedence over its quantity.

3. Sensors: Let the agent observe the actual application

This is arguably the most important part of a Maestro-based agent harness.

An agent generating UI automation must be able to observe what actually happens on the device. Otherwise, it is writing tests against its assumptions about the application.

Maestro already provides useful inspection capabilities.

The maestro hierarchy command prints the current application's view hierarchy. Maestro Studio also provides visual element selection and an interactive command runner.

These capabilities can become part of the agent’s toolset.

For example, expose a small set of tools through an MCP server or equivalent coding-agent integration:

These are proposed harness tools, not a claim that Maestro ships all of them as native MCP endpoints. They can be implemented as thin wrappers around Maestro CLI, ADB, simulator tooling, and repository scripts.

A useful tool response should contain structured information rather than only returning a large unfiltered terminal output.

For example, inspect_screen could return:

{
  "screen": "Login",
  "platform": "Android",
  "elements": [
    {
      "text": "Email",
      "id": "login_email",
      "type": "EditText"
    },
    {
      "text": "Password",
      "id": "login_password",
      "type": "EditText"
    },
    {
      "text": "Sign in",
      "id": "login_button",
      "type": "Button"
    }
  ]
}

An illustrative response format for your custom inspection tool.

The agent can now identify actual elements instead of inventing selectors. It is important to note that the screenshot and accessibility tree are different.

The screenshot gives you information about what the page looks like. The accessibility hierarchy provides machine-readable information about interactive elements.

Both are helpful. The screenshot lets the agent know how the page is laid out, and the accessibility tree helps create reliable Maestro selectors.

Maestro’s selector system supports text and accessibility identifiers, among other selector types.

For native Android Compose applications, test tags can be exposed as resource IDs using
Modifier.semantics { testTagsAsResourceId = true }.
On SwiftUI,
.accessibilityIdentifier() provides a stable identifier.

The harness should also detect when an element is not exposed through accessibility metadata. That is an application observability gap, not an invitation for the agent to guess coordinates.

4. Tools: Give the agent the ability to act and verify

Observation alone doesn’t complete the workflow. The agent needs tools to build, install, launch, interact with, and test the application.

A practical toolset should expose a small number of well-defined operations:

Build and device operations

• Build the required application variant.
• Install the generated APK or application bundle.
• Launch or restart the application.
• Reset application state.
• Select or identify the target device.

Inspection operations

• Capture screenshots.
• Retrieve the current UI hierarchy.
• Read application logs.
• Inspect the device and application state.

Automation operations

• Execute a specific Maestro flow.
• Execute a filtered test suite.
• Retrieve execution artifacts.
• Generate a structured test report.

The operations should be exposed through MCP, shell wrappers or native tools supported by the coding agent. The key thing here is that you are exposing functionality, instead of providing the agent an unrestricted environment.

For example, a run_maestro_flow tool should accept a flow path, target device, and approved parameters. It should return the execution status and artifact locations.

You shouldn’t need to build complex shell commands each time. Or try to figure out how to call it.

Limit what the agent can do and keep the permissions bounded. For example, if they are writing UI tests, they should generally only be able to read the application code, create/modify Maestro flows, and run approved test commands.

They shouldn’t be able to change how the application behaves in production without being aware, turn off existing tests, or change the expected results to make the outcome green. Secrets should be injected through the execution environment, not committed into generated YAML.

5. Orchestration: Build a closed-loop test-generation workflow

The previous components become useful when they operate as one workflow.

A test-generation agent should follow a repeatable sequence:

Consider a login test.

The task description is:

Generate a Maestro test that verifies successful login with valid credentials.

The harness should guide the agent through the following process.

Step 1: Understand the requirement

Find out the starting state of the application, a valid test account, the destination screen after authentication, any relevant constraints, etc.

Step 2: Explore the Application

Explore the source code for the login flow and already present flows.
Run the app and obtain its current UI hierarchy.
Find out the email ID field, password field, login button, and destination screen.

Step 3: Create the Test Plan

Find out what actions need to be performed and what assertions need to be made in order to prove the outcome.
The plan must differentiate between the action and the outcome. Pressing on Sign in is an action, while landing on the authenticated home screen is the outcome.

Step 4: Create the Flow

Create the Maestro YAML using the discovered identifiers.

For example:

appId: com.example.shop
name: Login with valid credentials

tags:
  - smoke
  - authentication
---
- launchApp:
    clearState: true
- tapOn:
    id: "login_email"
- inputText: ${USERNAME}
- tapOn:
    id: "login_password"
- inputText: ${PASSWORD}
- tapOn:
    id: "login_button"
- assertVisible:
    id: "home_screen"

These identifiers serve only as examples. The real agent has to determine them based on the accessibility hierarchy of the application or repository-supported UI contract.

Credentials should be supplied externally:

maestro test \
  -e USERNAME="$TEST_USERNAME" \
  -e PASSWORD="$TEST_PASSWORD" \
  .maestro/flows/auth/login.yaml

Maestro allows external parameters through the CLI -e option. It prevents hardcoding environment-specific credentials in the Flow. For more information, see Parameters and Constants.

Step 5: Execute and inspect

The agent executes the generated Flow against the target application.

A successful YAML parse is not sufficient. The actual interaction must run, and the expected authenticated state must appear.

Step 6: Identify the reason for failure

Suppose assertVisible fails.

The agent should look at the screenshot, the hierarchy, and the application logs rather than changing the selector or the interaction itself.

The failure could indicate:

• Incorrect selector.
• Unexpected state of the application.
• Failed authentication attempt.
• Backend issue.
• Application bug.

Different situations call for different actions.

An agent that simply changes the assertion or adds a delay until the test passes is not performing meaningful verification.

It is optimizing for a green result.

6. Sensors and verification: Make correctness measurable

A major mistake in AI-generated test automation is treating successful execution as proof of test quality.

The Flow can pass without checking for the critical behavior.

For example:

- tapOn: "Place order"
- assertVisible: "Order"

This test assertion can pass since there was a label for the order information already visible on the screen.

A better test assertion would check for a meaningful postcondition, like an order confirmation ID or confirmation status, if the application provides this feature.

The harness should thus verify the generated tests on two levels.

Structural validation

Check whether the generated Flow follows the repository’s conventions.

Useful checks include:

• Valid YAML structure.
• Correct application identifier.
• Approved directory and naming convention.
• No hardcoded credentials.
• No unapproved coordinate selectors.
• Meaningful assertions for the requested behavior.
• Reuse of existing subflows where appropriate.

These can be implemented as deterministic scripts or custom validators.

Runtime validation

Execute the Flow using the actual Maestro CLI and collect the resulting evidence.

For example:

maestro test \
  --format junit \
  --output build/maestro/report.xml \
  --test-output-dir build/maestro/artifacts \
  .maestro/flows/auth/login.yaml

Maestro supports JUnit reports, screenshots, recordings, command execution data, and other debugging artifacts. These can be consumed by the agent during its refinement loop.

Maestro supports JUnit reports, screenshots, recordings, command execution data, and other debugging artifacts. These can be consumed by the agent during its refinement loop.

See Maestro Test Reports and Artifacts.

I would also recommend adding a quality check that poses the following hard question:

Would the test fail if the expected application behavior were broken?

For critical scenarios, answer this question based on an intentionally wrong application state or a negative test fixture.

Just because a test reaches a screen does not mean that it is validating the expected business behavior.

7. Turn agent mistakes into permanent harness improvements

This is where harness engineering moves beyond an individual test-generation workflow.

Consider several recurring failures:

A repeated mistake should lead to a change in the instructions, tool capabilities, validation scripts, repository documentation, or orchestration workflow.

For example, telling an agent not to use coordinates might reduce the problem temporarily. A static validation rule that rejects unapproved point selectors provides a stronger and repeatable control.

Similarly, telling an agent to inspect the hierarchy is useful. Providing a dedicated tool that retrieves and filters the actual hierarchy makes that instruction actionable.

This is the engineering feedback loop.

8. Evaluate the harness, not just the generated tests

A good way to evaluate your agent is to look at more than just the number of YAML files created.

Define a set of authoring tasks that your agent will complete:

• Create a login flow
• Add to an existing checkout flow
• Create a negative auth scenario
• Deal with a platform specific selector
• Debug a failing assertion
• Reuse a subflow without duplicating interactions

Test these tasks against known application builds and test data.

Evaluate whether the agent:

1. Understand what behaviour is expected
2. Uses actual UI identifiers rather than guesses
3. Create valid Maestro flows
4. Successfully run the tests created
5. Detects failures when something is broken intentionally
6. Respect any existing test standards and assertions
7. Create a clear summary showing evidence of execution

Look at how well the agent performed on the first attempt.
How many times did it need to fix itself?
How many unnecessary changes were made to the application?
Did it use fragile selectors?
How many manual changes were made?

This helps you understand if your model, instructions, inspection tool or validation are actually improving the system.

A better model may improve the reasoning, but if your inspection tool is not giving full information about the UI or your validation accepts meaningless assertions.

The agent is only as capable as the environment it can observe

Maestro has made UI automation accessible through Flows, which capture the interactions and assertions in human-readable YAML. This readability also makes it fairly simple for an AI coding agent to author test files.

The much harder question is determining if the test files created by the agent are capturing real application behavior.

This will require an engineering framework around the modeling approach: repository guidance, application context, UI interrogation, controlled tooling, execution feedback, and deterministic validation.

I would approach this framework as an ever-evolving component of the test automation platform and not simply as a set of prompts.

Every time the agent invents a selector, misunderstands or misinterprets a screen, dilutes an assertion, or fails to detect a runtime error, there is an opportunity to improve the system that surrounds it.

The goal is not to generate more Maestro tests with AI. It is to build an agent that can engineer, execute, and verify meaningful UI tests with progressively less intervention from engineers.

Sources

• My AI Adoption Journey (February 5, 2026), Mitchell Hashimoto
• Engineering the Harness: A Practical Pattern for Reliable Coding Agents, Thoughtworks
• Maestro Flows Overview
• Core Selectors
• Parameters and Constants
• Test Reports and Artifacts
• Jetpack Compose
• SwiftUI

This story is published under the Generative AI publication. Connect with us on LinkedIn and follow Zeniteq to stay in the loop with the latest AI stories. Let’s shape the future of AI together!

Beyond Prompting: Harness Engineering for AI-Generated Maestro Tests was originally published in Generative AI on Medium, where people are continuing the conversation by highlighting and responding to this story.

Does AI make you dumber? The honest answer from the research so far is no, not in general. But one specific way of using it does make you worse at the task once the AI is gone: asking it for the finished answer before you’ve done any thinking of your own.

Several randomized experiments now point the same way, and the gap between people who use AI well and badly is often bigger than the gap between AI users and non-users.

I’ve long suspected that people keep much less of what they hear in long podcasts than they think they do. AI summaries promise a shortcut around that problem. So I wanted to know what the evidence says about learning from AI, and where exactly the cost comes from.

The study everyone quotes

The one that made the headlines came from the MIT Media Lab in 2025. Nataliya Kosmyna and colleagues had 54 people write essays with ChatGPT, with a search engine, or with no tools, while EEG recorded their brain activity.

The ChatGPT group showed the weakest neural connectivity. And when asked to quote a sentence from an essay they had written minutes earlier, 15 of the 18 ChatGPT users couldn’t do it accurately. In each of the other groups, only 2 of 18 had that trouble.

That last detail is striking, but the study is small, it’s a preprint, and it tested one task: writing an essay you didn’t really have to write. It’s a warning sign, not a verdict. The more convincing evidence came later, from larger trials.

What the bigger experiments found

In a field experiment in a Turkish high school, Hamsa Bastani and colleagues gave nearly 1,000 students access to GPT-4 during math practice. One group got a plain ChatGPT-style interface. Another got a version prompted to act as a tutor and give hints rather than answers.

During practice, the plain version improved scores by 48% and the tutor by 127%. Then came an exam without AI. Students who had practised with the plain version scored 17% lower than students who had never had AI. The tutor group showed no such drop.

A 2026 paper presented at the Conference on Language Modeling took the same question into a lab, across 1,222 people. Grace Liu, Brian Christian, and colleagues gave participants fraction problems or SAT reading questions, with GPT-5 in a sidebar for some of them, then took the AI away without warning.

In the first experiment, people who’d had AI solved 57% of the final problems, compared with 74% for people who never had it, and they skipped problems almost twice as often. The AI session lasted only 10 to 15 minutes.

The detail that matters most is in the second experiment. When the researchers split AI users by how they had used it, the drop was concentrated among the 61% who used it mainly to get answers. People who used it for hints or clarifications did about as well as people with no AI at all.

Coding shows the same split. In a randomized study by Anthropic researchers Judy Hanwen Shen and Alex Tamkin, 52 developers learned a Python library they hadn’t used before, with or without an AI assistant.

The AI group scored 17% lower on a quiz about the library and wasn’t significantly faster. But the AI users weren’t all alike. Those who asked conceptual questions, or asked for explanations alongside generated code, scored far higher than those who handed the task over.

What about summaries?

Most of those studies are about solving problems. If you use AI the way I’m interested in, to digest long content, the most relevant paper is by Shiri Melumad and Jin Ho Yun at the University of Pennsylvania.

Across seven experiments with more than 10,000 participants, people learned about a topic, such as how to grow a vegetable garden, either from an LLM or from ordinary Google results, and then wrote advice for a friend.

The LLM learners felt they’d learned less, put in less effort, and wrote advice that was shorter, less factual, and more generic. Independent readers, who didn’t know which tool had been used, found it less helpful.

This held even when both groups saw the same set of facts. And when the researchers gave people a version that showed source links next to its summary, it didn’t help, because once people had the summary, they weren’t motivated to dig into the sources. The summary felt like the end of the job.

Retention follows the same line. In a 2025 trial with 120 business students, André Barcaui had half learn a topic with ChatGPT and half with traditional methods, then gave everyone a surprise test 45 days later. The ChatGPT group scored 57.5% against 68.5%. They had also studied for less time, but the gap remained after accounting for that.

The evidence on the other side

It would be easy to stop there and conclude that AI is bad for learning. The research doesn’t support that either.

At Harvard, Gregory Kestin and colleagues ran a randomized trial with 194 physics students. An AI tutor, built to guide students through problems step by step, produced learning gains more than double those of an in-class active-learning lesson, in less time.

And a 2026 experiment in Frontiers in Psychology, with 659 participants in its main analysis, tested the order of use directly. One group wrote down their own position on an essay topic first and only then questioned the AI. Another group adopted what the AI gave them. Then everyone wrote a second essay with no AI.

The direct adopters reasoned worse than people who had never used AI. The think-first group did not fall below that baseline. The effect was small, but in the authors’ words, “What separated the arms was not access to the model but the order in which the interaction required the user to produce something.”

The pattern underneath

Put these side by side and a fairly consistent picture appears. The cost shows up when AI does the part of the work that produces learning: retrieving, struggling, connecting, and putting things in your own words. It largely disappears when the AI is set up, by its designers or by you, to make you do that part.

That fits older findings that have nothing to do with AI. In a classic 2006 study, Henry Roediger and Jeffrey Karpicke showed that trying to recall material beat rereading it on tests days later, even though rereading felt more productive. A polished AI summary is the ultimate rereading. It feels like understanding and asks nothing of you.

A Microsoft Research survey of 319 knowledge workers adds a self-reported angle. The more confidence people had in generative AI, the less critical thinking they reported putting into tasks. The more confidence they had in themselves, the more they reported.

How to use AI summaries without paying for it

None of this means giving up summaries. It means changing what you ask for and when.

Decide whether you’re looking something up or learning it. For a quick fact, a summary is the right tool. Melumad’s own advice is that the cost appears when the goal is deeper knowledge you’ll use later.

Think first, then ask. Before you open a summary of an episode or article you’ve consumed, write two sentences on what you think the main point was. Then compare. This is the think-first order from the Frontiers study, and it takes a minute.

Ask for questions, not answers. The tutor-style setups in the Bastani and Liu studies worked because they held the answer back. You can do that yourself:

I just listened to a podcast episode on [topic]. Don't summarize it.
Ask me five questions, one at a time, about its main ideas.
After each of my answers, tell me what I got right, what I missed,
and point me to the part of the transcript I should reread.

Use the summary as a map, not the destination. Let it tell you which 10 minutes of a two-hour episode are worth your attention, then go and listen to or read those 10 minutes yourself.

Close it and recall. After reading a summary, close the tab and write down the three points you’d act on. If you can’t, you’ve read it, but you haven’t kept it.

Where the evidence runs out

Most of these studies are short. Sessions lasted minutes or a few hours, and most tests came right afterwards. Only Barcaui’s waited weeks. Nobody yet knows what years of daily use do, in either direction.

The tasks are also narrow: fractions, SAT passages, essays, one coding library, gardening advice. The MIT study is small and not yet peer-reviewed. The Microsoft survey is self-reported and correlational. And participants in lab studies use AI the way an experiment allows, not the way they’d choose to.

What does hold across very different studies is the narrow claim. AI doesn’t make you dumber by being there. Letting it do your thinking before you’ve tried makes you worse at thinking without it, and that’s something you control every time you open a chat.

One thing to try

Next time you’re about to ask for a summary of something you want to remember, stop and write two sentences first. Then ask the AI what you missed.

This story is published under the Generative AI publication. Connect with us on LinkedIn and follow Zeniteq to stay in the loop with the latest AI stories. Let’s shape the future of AI together!

Does AI Make You Dumber? What the Studies Actually Measured was originally published in Generative AI on Medium, where people are continuing the conversation by highlighting and responding to this story.

The fastest way to summarize a podcast transcript with ChatGPT, Claude or Gemini is to paste the whole thing in and type “summarize this.” For a 20-minute episode, that’s usually fine.

For a two-hour interview, it tends to go wrong in two quiet ways: the middle of the conversation thins out, and some of the quotes come back smoother than anything the guest actually said.

Neither problem is a bug in one model. Both show up in published research on how language models handle long inputs, and both are easy to work around once you know where they come from.

Below is the workflow I’d use: split the transcript, extract before you summarize, and check the output against the source before you rely on it.

How long a two-hour transcript actually is

It helps to see the size of the job. The published transcript of Lex Fridman’s March 2024 conversation with Sam Altman runs just under two hours and comes to about 20,000 words, with roughly 500 timestamps. That fits comfortably inside the context window of every major chatbot today.

Fitting isn’t the problem. Using all of it evenly is.

Failure one: the middle goes missing

In 2023, Nelson Liu and colleagues at Stanford tested how well language models find information placed at different points in a long input. Performance was highest when the relevant passage sat near the beginning or end, and dropped significantly when it sat in the middle, even for models built for long contexts. They called it “lost in the middle.”

That study used question answering. A year later, Mathieu Ravaut and colleagues checked whether summaries have the same weakness. Across 6 models and 10 datasets, they found that the same U-shape holds for summarization: models lean on the start and end of the input and largely ignore what’s in between. When they built a test set where the important content sat in the middle, the models did noticeably worse.

A related study of book-length summaries, called FABLES, found that models systematically over-emphasized events near the end of the book and omitted important earlier material.

For a podcast, that’s a real loss. Hosts open with small talk and close with “where can people find you.” The part where the guest explains how they actually did the thing is usually somewhere around minute 40 to 80.

Ravaut’s team tested two fixes. One was summarizing the input in blocks and then summarizing the summaries. The other was building the summary up block by block. Both helped, especially for smaller models. They also tried simply asking the model to pay attention to the middle.

That worked reasonably well for GPT-3.5 but did little to change how the open models leaned on the start of the input. So asking nicely isn’t a strategy. Changing the shape of the input is.

Failure two: quotes that were never said

The second problem is faithfulness. The FABLES researchers had people who had read each book check 3,158 claims made in AI-written summaries. Most of the unfaithful claims concerned events and the state of characters, and they usually took some reasoning over the story to spot. A sentence could sound right and still be wrong.

The finding that matters most for this workflow: when the researchers asked language models to judge faithfulness, none of the AI raters agreed strongly with the human annotators, especially at catching the unfaithful claims. Asking the same chatbot “is this accurate?” is a weak check.

Outside the lab, the picture is similar. In a 2025 study coordinated by the EBU and led by the BBC, journalists reviewed more than 3,000 answers from ChatGPT, Copilot, Gemini and Perplexity about news stories.

31% had serious sourcing problems, meaning missing, misleading or wrong attributions. That’s news, not transcripts, but attribution is exactly what goes wrong when a summary puts a sentence in a guest’s mouth.

The workflow

Step 0: Get a transcript with timestamps and names

On YouTube, open the video description and click “Show transcript.” Many shows also publish their own transcripts, which are usually cleaner than auto-captions. Keep the timestamps and speaker names. They’re what make the later checks possible.

Step 1: Split it into chunks of 20 to 30 minutes

Use the timestamps to cut the transcript into four to six pieces, ideally at natural topic breaks. This is the “summarize in blocks” fix from the Ravaut paper, done by hand. It also means each chunk gets the model’s full attention, rather than competing with an hour of text on either side.

Step 2: Extract from each chunk, don’t summarize yet

Paste one chunk at a time with this prompt:

Below is one section of a podcast transcript (timestamps [START] to [END]).
Work only from this section.

List every distinct claim, recommendation, story or number the guest gives.
For each one:
- one plain sentence describing it
- the timestamp where it starts
- a short verbatim quote (8 to 20 words) copied exactly from the text

Rules:
- Copy quotes character for character. Do not tidy grammar or fill gaps.
- If you can't find an exact quote for a point, write NO QUOTE.
- If it's unclear who is speaking, write SPEAKER UNCLEAR.
- Leave out ads, intros and small talk.

[PASTE CHUNK]

Extraction is a narrower job than summarizing, so there’s less room to drift. The NO QUOTE and SPEAKER UNCLEAR options matter. They give the model a permitted way to say “I don’t know” instead of inventing something to fill the slot.

Step 3: Summarize the notes, not the transcript

Once every chunk is done, start a fresh chat and paste only the extracted notes:

These are notes extracted from a podcast, in order, with timestamps.
Write a summary of the main ideas.

- Keep the timestamp next to every point.
- Use only what is in the notes. Add nothing from outside knowledge.
- Give each section of the episode fair weight. Don't let the
  final section dominate.
- End with a short list of anything that looks contradictory
  or that the guest said with low confidence.

Because the model is now working from a few hundred lines rather than 20,000 words, the middle of the episode is no longer buried in the middle of a giant input.

Step 4: Turn it into actions, and label who said what

Summaries are good for remembering what was said. If you listened to learn something, you want the next step:

From these notes, list up to five concrete actions a listener could
take this week. Mark each one:
- GUEST: the guest recommended this directly (give the timestamp)
- INFERRED: you derived it from what they said

Don't present an INFERRED action as the guest's advice.

The GUEST/INFERRED label is the single most useful line in the whole workflow. Language models are good at turning a vague remark into a crisp instruction, and the crisp version is easy to misremember later as something the guest told you to do.

The five-minute check

Don’t skip this, because the research above says the model can’t reliably do it for you.

1. Search the quotes. Pick every quote you plan to reuse, copy four or five distinctive words, and Ctrl+F the transcript. If the phrase isn’t there, the quote isn’t real, however plausible it sounds.
2. Count by chunk. Look at how many points came from each section. If the second hour produced two points and the first 20 minutes produced eight, something was skimmed.
3. Spot-check one timestamp at random. Jump to it in the transcript or the video and read 30 seconds either side. Does the point match what’s there, including who said it?
4. Read the INFERRED list with suspicion. These are the model’s ideas, which can be useful, but they belong to the model, not the guest.

Which tool to use

The workflow works the same in ChatGPT, Claude, and Gemini, because it doesn’t depend on any one model’s features. NotebookLM takes a different route: you upload the transcript as a source, and its answers come with citations you can click back to the passage, which makes step 3 of the check faster. It still runs on a language model, so the same rules about quotes apply.

What this doesn’t fix

If the transcript is wrong, the summary will be too. Auto-captions mishear names, numbers, and jargon, so treat any figure in a summary as a pointer to go and listen to that moment, not as a fact.

It’s also slower. One prompt takes a minute; this takes ten to fifteen. For an episode you’ll never think about again, the one-prompt version is fine. The longer workflow is for the episodes where you want to act on what you heard or repeat it to someone else.

Models will keep improving, and some of these problems may shrink. But the habit of keeping timestamps, separating what was said from what was inferred, and checking quotes against the source will stay useful whatever model you use next year.

One thing to try

Take the last long episode you meant to learn from. Run step 2 on just the middle chunk and compare it with what you remember. If the notes surprise you, the middle was exactly the part you, and a one-shot summary, would have lost.

This story is published under the Generative AI publication. Connect with us on LinkedIn and follow Zeniteq to stay in the loop with the latest AI stories. Let’s shape the future of AI together!

How to Summarize a Podcast Transcript With ChatGPT Without Losing the Middle was originally published in Generative AI on Medium, where people are continuing the conversation by highlighting and responding to this story.