DEV Community: Quinton

I tested OpenAI GPT-5. The results were not what I expected!

Quinton — Sat, 09 Aug 2025 19:39:07 +0000

In case you missed the news, OpenAI just released their new reasoning model, GPT-5. There is a lot of hype about it’s ability to performing reasoning tasks and it’s potential for software development. But what does it feel like in real-world developer usage?

I am currently using the OpenAI Responses API in my side project, mycaminoguide, an AI agent that works in WhatsApp and gives hikers planning, or on the Camino de Santiago, a way to ask for advice, like you would an experienced hiking friend. v1 of that app is published, but I want to improve the performance of it. (If you want to follow along on Youtube as I try out more AI tools to build it, I’d love if you subscribed, or left a thumbs up. Comments, views, and subs really help with motivation!) I’m hoping GPT-5 helps as part of the solution. For my day job, I am also working on some apps that use the Responses API to fetch and analyze customer data. These apps are much more standalone and make a good candidate for me to perform some simple real world performance test of GPT-5.

Full disclaimer: this is not an amazingly scientific or comprehensive test. I wanted to test real-world, average developer usage in a typical use case that I have.

Is GPT-5 faster than GPT-4.1?

Test 1: end-to-end analysis

The standalone app is written in Python with a Streamlit front end and uses the new Airbyte Embedded MCP to fetch Stripe invoice data on behalf of a customer. This data is used with the OpenAI’s Responses API to perform some analysis. I used Cline with GPT-4.1 to generate most of the code. The complete code of the main app is ~114 lines. You can see it all here in the repo. After fetching a Bearer token to authenticate against Airbyte, I make the call to OpenAI, and add a timer to track execution time. The full code I ran is here.

 import time
    with st.spinner("Fetching customer data via Airbyte Embedded and asking GPT to analyze it..."):
        start_time = time.time()
        resp = openai.responses.create(
            model="gpt-5",
            tools=[
                {
                    "type": "mcp",
                    "server_label": "airbyte-embedded-mcp",
                    "server_url": "https://mcp.airbyte.ai",
                    "headers": {
                        "Authorization": f"Bearer {AIRBYTE_BEARER_TOKEN}"
                    },
                    "require_approval": "never",
                },
            ],
            input=prompt,
        )
        duration = time.time() - start_time
    st.success(f"Request completed in {duration:.2f} seconds.")

I ran the process using GPT-4.1 three times with the results below.

	Test 1	Test 2	Test 3
OpenAI+Airbyte MCP	29.85 seconds	15.38 seconds	13.56 seconds

Now, let’s test GPT-5.

First, let’s run the exact same code with the only change being that I change the model from GPT-4.1 to 5.0. Here are the results of the three test executions.

	Test 1	Test 2	Test 3
OpenAI+Airbyte MCP	77.72 seconds	57.72 seconds	83.40 seconds

Wow! This is not what I expected at all. Chaining an MCP to return data which I pass to to GPT-5 for analysis is significantly slower than GPT-4.1. I’m shocked.

Test 2: removing the variance

Perhaps the MCP call is introducing variance? This MCP service calls Airbyte, which proxies a results to a data source - Stripe in my example - on behalf of a customer. This use case is very common for developers building AI apps where they want to fetch user data and pass it to an LLM. But there is a high chance any of these calls may take varying times to return the data.

Let’s separate out the data call and instead inject the data directly into the prompt. I saved this file as streamlit_app_test2.py and added timers to wrap both the MCP call and the OpenAI responses call.

 # 1) Fetch invoices from MCP server (outside OpenAI)
    fetch_start = time.time()
    invoices = fetch_invoices_via_mcp(AIRBYTE_BEARER_TOKEN, STRIPE_CONNECTOR_ID)
    fetch_duration = time.time() - fetch_start
    st.info(f"MCP fetch completed in {fetch_duration:.2f} seconds.")
    if invoices:
        st.success(f"Fetched {len(invoices)} invoices from MCP server.")
    else:
        st.info("No invoices returned from MCP server; analysis will proceed with empty data.")

    # 2) Build prompt by injecting fetched data
    base_prompt = (
        "You are an experienced financial planner and accountant. "
        "Analyze the provided Stripe invoice data and prepare a plan for me to manage my invoices."
    )
    invoices_for_prompt = simplify_invoices(invoices, limit=50)
    new_prompt = (
        f"{base_prompt}\n\n"
        f"Here is a JSON array of invoices (subset of fields, up to 50 rows):\n"
        f"{json.dumps(invoices_for_prompt, ensure_ascii=False)}\n\n"
        "Please provide:\n"
        "- Key insights and trends\n"
        "- Risk assessment (e.g., overdue, large unpaid balances)\n"
        "- A prioritized plan of actions\n"
        "- If useful, include a concise Markdown table summary (e.g., Invoice Number, Amount Due (USD), Status, Due Date)"
    )

    # 3) Ask OpenAI to analyze the injected data (no MCP tool usage here)
    with st.spinner("Analyzing invoice data with the model..."):
        start_time = time.time()
        resp = openai.responses.create(
            model=MODEL_NAME,
            input=new_prompt,
        )
        duration = time.time() - start_time
    st.success(f"Request completed in {duration:.2f} seconds.")

Here’s the results:

First, GPT-4.1

	Test 1	Test 2	Test 3
Proxy Call (seconds)	6.71	6.74	6.93
OpenAI call (seconds)	9.87	10.31	9.62

Next, GPT-5

	Test 1	Test 2	Test 3
Proxy Call (seconds)	7.85	7.01	7.11
OpenAI call (seconds)	80.01	46.05	48.06

The results are pretty clear! GPT-5 is significantly slower when using the Responses API. It’s not even close. And, you can see from the Proxy calls that there is very little variance which may be attributed to network latency. The Airbyte call, and subsequent Stripe proxy request is pretty fast.

Test 3: Does the Responses API introduce the variance?

What if it is not the model at all? Perhaps it is the OpenAI Responses API? Let’s take the prompt from test 2, which includes the data returned from the Airbyte Proxy request, and use chatGPT to perform the request using both GPT-4.1 and GPT-5.

Here is the complete prompt:

You are an experienced financial planner and accountant. Analyze the provided Stripe invoice data and prepare a plan for me to manage my invoices. In your output, tell me exactly how long in seconds it took you to perform this analysis. this time should be accurate to two decimal places

Here is a JSON array of invoices (subset of fields, up to 50 rows):
[{"id": "in_1RoWV6Jns63UPKMcLkpxPCCo", "customer": "cus_Sk0SaX89BlwYJR", "status": "draft", "amount_due": 30000, "currency": "usd", "due_date": null, "created": 1753391788, "paid": false, "amount_paid": 0}, {"id": "in_1RoWUmJns63UPKMco8KUcu88", "customer": "cus_Sk0TvnAQUT6rOX", "status": "draft", "amount_due": 60000, "currency": "usd", "due_date": null, "created": 1753391768, "paid": false, "amount_paid": 0}, {"id": "in_1RoWUTJns63UPKMch0nprHNh", "customer": "cus_Sk0T8SdwDgSMva", "status": "draft", "amount_due": 20000, "currency": "usd", "due_date": null, "created": 1753391749, "paid": false, "amount_paid": 0}, {"id": "in_1RoWU8Jns63UPKMcalyJvrAu", "customer": "cus_Sk0TM8UmpVhWJB", "status": "draft", "amount_due": 30000, "currency": "usd", "due_date": null, "created": 1753391728, "paid": false, "amount_paid": 0}, {"id": "in_1RoWTJJns63UPKMczVOgarPJ", "customer": "cus_Sk0U3CjIKfiGql", "status": "draft", "amount_due": 20000, "currency": "usd", "due_date": null, "created": 1753391677, "paid": false, "amount_paid": 0}]

Please provide:

Key insights and trends
Risk assessment (e.g., overdue, large unpaid balances)
A prioritized plan of actions
If useful, include a concise Markdown table summary (e.g., Invoice Number, Amount Due (USD), Status, Due Date)

Here are the results:

ChatGPT Client

	Test 1	Test 2	Test 3
GPT-4o	4.92	5.32	3.47
GPT-5	38.82	36.78	34.62

Note: The prompt includes a statement to print execution time. The results in chatGPT returned almost instantly, and then type out the response to the screen. It appears that chatGPT calculates execution time on how long it will take to complete the entire request, which includes printing it out to the screen. I also could only use 4o, not 4.1 on chatGPT.

So what’s the verdict?

I’ll be honest, I don’t know what to make of the results. Every single one of my non-scientific, real world developer tests indicate that GPT-5 is significantly slower than GPT-4.1/o. I didn’t review the analysis results between the two models. Perhaps better reasoning takes longer and the results are more in-depth, but it’s hard for an app developer to justify such a huge difference in performance.

Maybe GPT-5 is just getting overwhelmed with usage load at the moment? Next, I’d like to compare GPT-5 and GPT-OSS to take server load out of the equation, but I couldn’t find a clear answer to what actual model GPT-OSS is based upon. If anyone knows, please let me know, or if you are even interested in such a comparison. (I am kind of curious now, as well as testing GPT-5-mini)

In the meantime, back to coding, probably still with GPT-4. ;)

One-click MCP installs with npx

Quinton — Wed, 09 Jul 2025 19:55:42 +0000

A few weeks back I shipped the PyAirbyte MCP service for Airbyte. This service relies on OpenAI and Vector Embeddings to create an entire data pipeline with a single prompt. All you had to do was provide a source and destination from any of the hundreds of connectors available in the Airbyte Registry.

"create a data pipeline from source-postures to destination-data bricks"
_

The service has been getting heavy usage, which is always great. The biggest bit of feedback that I receive though, is "I wish it ran in Claude/Cline/Replit/etc".

The initial release was shipped as a remote MCP server running on Heroku. This implementation relies on the user passing in their OpenAI API key, which the server uses, along with the vector embed search, to determine how to generate the right code. All sounds great until you dig into the how different vendors implement the mcp.json spec. At the time of publishing the MCP, only Cursor allows the passing in of environment variables within mcp.json for remote servers. I wanted to ship v1 as fast as possible, so I decided to only support Cursor -- not a bad thing if a million developers already use it, right?

"pyairbyte-mcp": {
      "url": "https://pyairbyte-mcp-7b7b8566f2ce.herokuapp.com/mcp",
      "env": {
        "OPENAI_API_KEY": "your-openai-api-key"
      }
    }

NPX - the secret ingredient

After shipping v1, I wanted to find a way to easily allow developers to add the MCP server to whatever AI tool they wanted. I'm a big fan of Cline for my IDE and Claude Desktop as my AI Guide to the Galaxy. With a little digging, npx seemed to the secret ingredient.

NPX is a CLI tool for installing and managing dependencies of a host npm package on npmjs.com. Since NPX is a CLI tool, you can execute it as part of the mcp.json spec:

"fast-pyairbyte": {
      "command": "npx",
      "args": ["fast-pyairbyte"],
      "env": {
        "OPENAI_API_KEY": "your-key-here"
      }
    }

From my testing, all of the major apps that support MCP.json handle npx great. To the app it is just another local execution. To the user, it is a single step install. Here is the MCP running right within Claude Desktop.

Try it for yourself

The MCP is now an official package on npmjs.com, under the name fast-pyairbyte. Cursor still leads the way in terms of developer experience to install an MCP server with one click installs:

If you are using Cline, Claude, or pretty much any other tool, you can add Fast PyAirbyte by including the json snippet into the relevant config files:

For Cursor (.cursor/mcp.json):

{
  "mcpServers": {
    "fast-pyairbyte": {
      "command": "npx",
      "args": ["fast-pyairbyte"],
      "env": {
        "OPENAI_API_KEY": "your-openai-api-key-here"
      }
    }
  }
}

For Claude Desktop (~/.config/claude/claude_desktop_config.json):

{
  "mcpServers": {
    "fast-pyairbyte": {
      "command": "npx",
      "args": ["fast-pyairbyte"],
      "env": {
        "OPENAI_API_KEY": "your-openai-api-key-here"
      }
    }
  }
}

For Cline (~/.config/cline/mcp_settings.json):

{
  "mcpServers": {
    "fast-pyairbyte": {
      "command": "npx",
      "args": ["fast-pyairbyte"],
      "env": {
        "OPENAI_API_KEY": "your-openai-api-key-here"
      }
    }
  }
}

Real world lessons from building MCP servers

Quinton — Fri, 20 Jun 2025 19:30:26 +0000

MCP servers are everywhere now. Whether you are using tools like Claude Desktop, ChatGPT, Cursor, Cline, Postman, you name it; If a developer can plug in an MCP to it, they will. Having built a number of MCP servers recently at Airbyte, and running my own side hustle at mycaminoguide.com as an AI agent for the past year, I've learned a few things about what it really takes to build and run MCP servers.

Know the main components of an MCP server.

This might sound obvious, but knowing the main components of an MCP server is incredibly helpful as you build your own. It gives you a roadmap on what and how you want to implement services, and will save you significant time trying to custom code your own solutions when you should have used native MCP decorators and support.

Tools: Tools are functions clients can call to perform an action. Tools are what show up in something like Cursor. When designing an MCP, I typically start by thinking about the domain I want to work in. eg: functions a developer needs when working with my product, or calendar functions etc. From there I have a scope and can decide what actaul functions are available. If I find I am exceeding the domain, I typically create a separate MCP server.

Resources: Resources allow your client to return specific data based on parameters. Resources are very helpful if your MCP service is going to perform some sort of query on a backend system. eg: My MCP offers a calendar service and I want to pass in a particular date to get availability.

@mcp.resource("availability://{user_id}/date")

Prompts: Prompts are messages templates that include parameterized values that you can pass to an LLM to perform a query. I use prompts extensively within the PyAirbyte MCP server to allow the user to specify source and destination connectors. The MCP server then uses a consistent prompt and the OpenAI chat completion API to query the vector store for highly relevant results.

Understand the Transports

Clients support different transports depending on your deployment model.

stdio

If you are running locally, the transport is going to be stdio. Effectively, you configuring your mcp to execute a shell command to run a local file. I use stdio MCP services that I have built to help me automate frequent daily tasks such as checking the health of pipelines, looking at usage analytics, slack summaries etc from within Claude Desktop. I wouldn't recommend stdio for broader developer community facing tools. There is too much local config that the user needs to manage.

{
  "mcpServers": {
    "airbyte-status-checker": {
      "command": "/Users/quintonwall/.local/bin/uv",
      "args": [
        "--directory",
        "/Users/quintonwall/code/airbyte-mcp-list-sources",
        "run",
        "airbyte_status_checker.py"
      ]
    },
    "movedata-demo": {
      "command": "/Users/quintonwall/.local/bin/uv",
      "args": [
        "--directory",
        "/Users/quintonwall/code/movedata-demo-project",
        "run",
        "mcp_server.py"
      ]
    }
  }
}

SSE

Server Sent Events, or SSE, is the original transport for remote MCP servers. MCP servers built using this model require you to run a server such as Express or FastMCP to serve endpoints, both a POST and GET. Remote servers in general are not supported by Claude Desktop, but are supported in Cursor and Cline, although there are limitations, which I'll cover shortly. If you are starting to write MCP servers today, I would not recommend using SSE transports as they have been deprecated in favor of Streamable transports.

Streamable HTTP

Streamable HTTP transports removes the need to create two endpoints - a POST and GET - like you see in SSE transports and are slightly more complex to set up. Once you do have them configured though, there is a lot of benefits through scalability and resumable connections. In addition, they can work stateless meaning you can deploy them quite easily on Vercel vs. SSE services which you need to deploy on something like Railway or Heroku. The downside is that the Streamable HTTP transport is very new with Client tool vendors only now implementing it. There are positive sign though that this transport will become the most dominant. I've already see Claude Code implement a --transport http parameter, for example.

from fastapi import FastAPI, Request
from fastapi.responses import JSONResponse, StreamingResponse
import asyncio
import json

app = FastAPI()

@app.post("/mcp")
async def handle_mcp(request: Request):
    body = await request.json()

    method = body.get("method")
    if method == "tool/echo":
        params = body.get("params", {})
        stream = params.get("stream", False)

        if stream:
            async def stream_response():
                for i in range(3):
                    event = {
                        "jsonrpc": "2.0",
                        "id": body.get("id"),
                        "result": {"message": f"streaming chunk {i}"}
                    }
                    yield f"data: {json.dumps(event)}\n\n"
                    await asyncio.sleep(0.5)
            return StreamingResponse(stream_response(), media_type="text/event-stream")

        # Non-streaming response
        return JSONResponse({
            "jsonrpc": "2.0",
            "id": body.get("id"),
            "result": {"message": "echo response"}
        })

    return JSONResponse({
        "jsonrpc": "2.0",
        "id": body.get("id"),
        "error": {"code": -32601, "message": "Method not found"}
    })

# Run with: uvicorn app:app --reload

Utilize a good library

Most of my MCP development is done in python. Thankfully, there is a rich ecosystem of libraries available to that make working with MCP much easier.

FastMCP

FastMCP is the defacto standard. It is fully spec-compliant, supports streaming transport, and is easily deployed.

from fastmcp import MCPApp
app = MCPApp()

@app.tool("math/add")
def add(a: int, b: int) -> int:
    return a + b

OpenAI Responses API

It's been interesting to see OpenAI support a competitors 'standard' (Anthrophic were the original authors of the MCP spec). As a heavy user of the Responses API in mycaminoguide.com, I've been excited to see that models can now use MCP servers to perform tasks. Currently the implementation doesn't feel very natural and there it's overly complex but the idea of an agent or model using my MCP server has me watching this space closely. Google is also pushing the same approach with their Agent SDK.

Not all Clients are created equal

When it client tools such as Claude Desktop, Cline, and Cursor, etc, the level of support for the MCP spec, and how this is represented in the mcp.json a user needs to add to connect a server can often lead to wasted time trying to figure out why an error is being raised. I have not found a centralized place where these differences are listed. Here are the ones I have encountered

Local MCP server support: Claude Desktop, Cline, Cursor, Claude Code.
Remote MCP server support: Cline, Cursor, Claude Code
Remote MCP server passing env in mcp.json: Cursor, Claude Code

The remote MCP server with support for passing environment variables is a interesting case. For example, we just deployed an MCP server for PyAirbyte. This server uses openAI and a vector store to generate data pipelines. It is deployed on Heroku. As part of the client config, we require that you pass in your OpenAI API key. This works great within Cursor, but unfortunately it not supported in Cline. You can, of course, add values to a serverside .env file, but we did not want to do this due to the risk of someone spamming the MCP server and running up a bit OpenAI bill.

{
  "mcpServers": {
    "pyairbyte-mcp": {
      "url": "https://pyairbyte-mcp-7b7b8566f2ce.herokuapp.com/mcp",
      "env": {
        "OPENAI_API_KEY": "your-api-key"
      }
    }
  }
}

Summary

MCP protocols are still evolving. Change is constant and can be frustrating when building services. Sometimes logging errors are not very helpful, and LLMs like ChatGPT often send you down a rabbit hole, only to find out that the spec has changed and the LLM doesn't have the most recent information. Vibe coding MCP servers can be an exercise in frustration. I hope these tips help you get started in building your own MCP servers and avoid some of the pitfalls I made when starting out.

Creating Stripe Test Data in Python

Quinton — Thu, 26 Dec 2024 19:31:24 +0000

We've been working on a new AI+data course to show how you can build a AI chatbot by moving e-commerce data from Stripe into PGVector running on Supabase, via Airbyte PGVector connector to create OpenAI embeddings, using OpenAI client libraries to add natural language support into an app. This is a pretty common "intelligent data stack" app pattern that many of our customers are implementing. The source and destination may change, but pattern (data source > move data and create embeddings > vector-enabled data store > web app with OpenAI) stays the same.

Since we are working on course that is intended for folks to get hands on with, we wanted to make set up as easy as possible. A big part of this was creating sufficient test data in Stripe so there would be a reasonable dataset for the chatbot to interact with. If you've used Stripe before, you know they have a great Sandbox where you can experiment with. The only problem is that it doesn't have sample data pre-loaded.

There are a few sample datasets you can load via the CLI fixtures command. But, for our use, these didn't fit the need. We wanted a larger data set, and since this material will be used online and in workshops, asking learners to install something, like the CLI, on their local machines opens you up to a whole bunch of complexity dealing. You never know what OS version the user is running, whether they have the correct permissions to install things, and so much more. I've been burnt too many times to go down that road.

Thankfully, Stripe also has fantastic APIs, and a great Python client which means we could quickly create a collab notebook for learners to run and insert the data we wanted.

After installing the stripe library via !pip install stripe and passing in a test key using Google Collab secrets, we had to set up some random names for customers and products. The goal was to insert a random collection customers, products with different prices, and purchases. This way when we ask the chatbot questions like "who made the cheapest purchase? How much did they pay, and what did they buy?" there was sufficient data.

import stripe
import random
from google.colab import userdata


stripe.api_key = userdata.get('STRIPE_TEST_KEY')


# Sample data for generating random names
first_names = ["Alice", "Bob", "Charlie", "Diana", "Eve", "Frank", "Grace", "Hank", "Ivy", "Jack", "Quinton", "Akriti", "Justin", "Marcos"]
last_names = ["Smith", "Johnson", "Williams", "Jones", "Brown", "Davis", "Miller", "Wilson", "Moore", "Taylor", "Wall", "Chau", "Keswani", "Marx"]
# Sample clothing product names
clothing_names = [
    "T-Shirt", "Jeans", "Jacket", "Sweater", "Hoodie",
    "Shorts", "Dress", "Blouse", "Skirt", "Pants",
    "Shoes", "Sandals", "Sneakers", "Socks", "Hat",
    "Scarf", "Gloves", "Coat", "Belt", "Tie",
    "Tank Top", "Cardigan", "Overalls", "Tracksuit", "Polo Shirt",
    "Cargo Pants", "Capris", "Dungarees", "Boots", "Cufflinks",
    "Raincoat", "Peacoat", "Blazer", "Slippers", "Underwear",
    "Leggings", "Windbreaker", "Tracksuit Bottoms", "Beanie", "Bikini"
]
# List of random colors
colors = [
    "Red", "Blue", "Green", "Yellow", "Black", "White", "Gray",
    "Pink", "Purple", "Orange", "Brown", "Teal", "Navy", "Maroon",
    "Gold", "Silver", "Beige", "Lavender", "Turquoise", "Coral"
]

Next, it was time to add functions for each of the data types in Stripe that we needed.


# Function to create sample customers with random names
def create_customers(count=5):
    customers = []
    for _ in range(count):
        first_name = random.choice(first_names)
        last_name = random.choice(last_names)
        name = f"{first_name} {last_name}"
        email = f"{first_name.lower()}.{last_name.lower()}@example.com"

        customer = stripe.Customer.create(
            name=name,
            email=email,
            description="Sample customer for testing"
        )
        customers.append(customer)
        print(f"Created Customer: {customer['name']} (ID: {customer['id']})")
    return customers

# Function to create sample products with random clothing names and colors
def create_products(count=3):
    products = []
    for _ in range(count):
        color = random.choice(colors)
        product_name = random.choice(clothing_names)
        full_name = f"{color} {product_name}"
        product = stripe.Product.create(
            name=full_name,
            description=f"This is a {color.lower()} {product_name.lower()}"
        )
        products.append(product)
        print(f"Created Product: {product['name']} (ID: {product['id']})")
    return products

# Function to create prices for the products with random unit_amount
def create_prices(products, min_price=500, max_price=5000):
    prices = []
    for product in products:
        unit_amount = random.randint(min_price, max_price)  # Random amount in cents
        price = stripe.Price.create(
            unit_amount=unit_amount,
            currency="usd",
            product=product['id']
        )
        prices.append(price)
        print(f"Created Price: ${unit_amount / 100:.2f} for Product {product['name']} (ID: {price['id']})")
    return prices

# Function to create random purchases for each customer
def create_purchases(customers, prices, max_purchases_per_customer=5):
    purchases = []
    for customer in customers:
        num_purchases = random.randint(1, max_purchases_per_customer)  # Random number of purchases per customer
        for _ in range(num_purchases):
            price = random.choice(prices)  # Randomly select a product's price
            purchase = stripe.PaymentIntent.create(
                amount=price['unit_amount'],  # Amount in cents
                currency=price['currency'],
                customer=customer['id'],
                payment_method_types=["card"],  # Simulate card payment
                description=f"Purchase of {price['product']} by {customer['name']}"
            )
            purchases.append(purchase)
            print(f"Created Purchase for Customer {customer['name']} (Amount: ${price['unit_amount'] / 100:.2f})")
    return purchases

All that was left is to run the script and specify how much data we need.

# Main function to create sample data
def main():
    print("Creating sample customers with random names...")
    customers = create_customers(count=20)

    print("\nCreating sample products with random clothing names and colors...")
    products = create_products(count=30)

    print("\nCreating prices for products with random amounts...")
    prices = create_prices(products, min_price=500, max_price=5000)

    print("\nCreating random purchases for each customer...")
    purchases = create_purchases(customers, prices, max_purchases_per_customer=10)

    print("\nSample data creation complete!")
    print(f"Created {len(customers)} customers, {len(products)} products, and {len(purchases)} purchases.")

if __name__ == "__main__":
    main()

With the data loaded into our Stripe Sandbox, hooking it up to Airbyte only took a few minutes by using the Connector Builder to map the API endpoints to streams for each data type and setting up a sync job.

Problem solved! Our Collab Python script is super easy for the learner to insert test data into Stripe. Hope it's helpful for someone else doing similar testing.

Can AI finally generate best practice code? I think so.

Quinton — Thu, 19 Dec 2024 21:05:14 +0000

The other week I posted about best practices and pro tips on creating prompts with Cursor. At the heart of these tips was the idea of providing the composer as much context as possible.

In Cursor you could this through two primary ways:

By @mentioning docs or code directly into the composer window or via Cursor settings
Generally by creating more prescriptive prompts such as “always use .env files for storing credentials”

Using @mentions in Cursor

If there is anything you get used to working in tech, and especially now with AI, is the rapid pace of change.

Since I wrote that post, a LOT has changed. Tools like Cursor and Windsurf have introduced rules files. Rules files, and understanding which LLM are best for what task, are a game changer for how I’ve been working with prompts and coding.

You can think of rules files are a place where you can specify longer, more prescriptive rules that your prompts in your project must follow. If you are used to working with dependency files in coding, it’s kind of like this but on steroids.

At the same time, we’ve moved from generative AI assistants to collaborative agentic AI.

Put these together, and the results are pretty amazing!

Here’s an example.

Let’s say I’m using Cursor to build a bunch of data apps and using Airbyte as the data movement platform and Streamlit for the frontend. I’m writing in Python and using the Airbyte API libraries. This is my basic ‘tech stack’.

I can define this in my .cursorrules file that I put in the root of my project folder.

- name: "Import Required Libraries"
    action: "Always ensure the required libraries are imported at the top of the file."
    details:
      - "os: To load environment variables."
      - "dotenv: To load .env file for credentials."
      - "pandas: For mapping API results to DataFrame."
      - "airbyte_api_client: For interacting with Airbyte APIs."
      - "airbyte_api_client.api: Import API-specific modules."
      - "airbyte_api_client.configuration: To configure the API client."
      - "requests: For token management and refreshing the token."

I can go further as well and tell Cursor some of my coding preferences, such as how I want to authenticate, store sensitive keys, and how to work with data.

- name: "Store Sensitive Information Securely"
    action: "All API keys, tokens, client IDs, and client secrets must be stored in a .env file."
    details:
      - ".env file example:"
        content: |
          AIRBYTE_API_URL=https://your-airbyte-instance.com
          AIRBYTE_CLIENT_ID=your_client_id
          AIRBYTE_CLIENT_SECRET=your_client_secret
      - "Load credentials using the python-dotenv library."
      - "Example code:"
        content: |
          from dotenv import load_dotenv
          import os
          load_dotenv()
          AIRBYTE_API_URL = os.getenv('AIRBYTE_API_URL')
          AIRBYTE_CLIENT_ID = os.getenv('AIRBYTE_CLIENT_ID')
          AIRBYTE_CLIENT_SECRET = os.getenv('AIRBYTE_CLIENT_SECRET')

  - name: "Authenticate Using Bearer Token"
    action: "Use client and secret keys to fetch a new bearer token before making API requests."
    details:
      - "Add token refresh logic in a reusable function."
      - "Example function to get a fresh token:"
        content: |
          import requests

          def get_access_token():
              """
              Fetch a new access token using client ID and secret.

              Returns:
                  str: Bearer token.
              """
              url = f"{AIRBYTE_API_URL}/oauth/token"
              payload = {
                  "client_id": AIRBYTE_CLIENT_ID,
                  "client_secret": AIRBYTE_CLIENT_SECRET,
                  "grant_type": "client_credentials"
              }
              response = requests.post(url, json=payload)
              response.raise_for_status()
              return response.json()["access_token"]

Here’s where things really get interesting. I want my code to be easy to maintain and well structured. Early genAI assistants really struggled here. They often generated monolithic blocks of code, that whilst they worked, they were pretty ugly. I want my rules to tell Cursor how I like my code. Thankfully, agentic AI can use reasoning to figure out how to create well structured code. In the world of Python, PEP 8 provides a style guide for best practices on how to write good code. I can now tell Cursor to use this guide whenever it writes code!

- name: "Follow PEP8 Naming Conventions"
    action: "Ensure that variable, function, and class names adhere to PEP8 standards."
    details:
      - "Use snake_case for variable and function names."
      - "Use PascalCase for class names."
      - "Limit line length to 79 characters."
      - "Prefix all private variables and functions with an underscore."
       - "Use encapsulation for best practices"

Now, when I create rules, or generate code, my functions are neat, easy to read, and practices good encapsulation technics. All the things I would -- well, should -- do when coding.

 - name: "Map Results to pandas DataFrame"
    action: "Always convert API response data to pandas DataFrame for further processing."
    details:
      - "Example function to convert API response to DataFrame:"
        content: |
          import pandas as pd

          def map_to_dataframe(data, columns=None):
              """
              Convert API response data to pandas DataFrame.

              Args:
                  data (list or dict): JSON response data.
                  columns (list, optional): List of column names to include.

              Returns:
                  pd.DataFrame: Data in tabular format.
              """
              df = pd.DataFrame(data)
              if columns:
                  df = df[columns]
              return df

PEP 8, also offers guidelines for documenting code, how to handle error messages, and much more. I can add examples in my .cursorrules file that problems can use as context whenever creating new code.

- name: "Error Handling for API Requests"
    action: "Implement robust error handling for API calls."
    details:
      - "Use try-except blocks to handle common exceptions."
      - "Raise errors for debugging when necessary."
      - "Example:"
        content: |
          try:
              api_client = get_api_client()
              df = get_workspaces(api_client)
              print(df.head())
          except Exception as e:
              print(f"An error occurred: {e}")

Putting it all together, my current .cursorrules file for Airbyte development in Python means I can spend more time thinking about the task I want the prompt to perform vs. how to structure the actual prompt to create best practice code. This has saved me hours and hours of refactoring time.

And, since I switch between Python, React, and Swift on a regular basis, I’ve started creating rules files for each language. This approach let’s me apply best practices per language, define things like directory structures in my projects and much more. If you want to check out my rules files, I’ve added them to a GitHub repo. I'm constantly refactoring and adding more. Star and follow along if you want to stay up to date.

# CursorRules file for Xcode Swift Project
# Defines best practices for directory structure

# Base directory
ProjectRoot:
  - README.md           # Project documentation
  - LICENSE             # License file
  - .gitignore          # Git ignore rules
  - .xcodeproj          # Xcode project file
  - .xcworkspace        # Xcode workspace file (if using CocoaPods or similar)

# Primary folders
Sources:                # All source code files
  - App:                # Main app folder
    - Models:           # Data models
    - Views:            # User interface components
    - ViewModels:       # Logic connecting views and models (MVVM pattern)
    - Controllers:      # View controllers (MVC pattern)
  - Resources:          # Assets and other resources
    - Assets.xcassets   # Image and color assets
    - LaunchScreen.storyboard # Launch screen storyboard
    - Localizations:    # Localized strings and assets

Tests:                  # Unit and UI tests
  - UnitTests:          # Unit test cases
  - UITests:            # UI test cases

# Supporting files
Configurations:         # Build and app configurations
  - Debug.xcconfig      # Debug configuration settings
  - Release.xcconfig    # Release configuration settings

Extensions:             # Code extensions (e.g., for UIKit or SwiftUI)
  - String+Extensions.swift
  - Date+Extensions.swift

Utilities:              # General utilities and helpers
  - NetworkManager.swift
  - APIConstants.swift

# Example
Example:                # Example apps or demos
  - ExampleApp:         # Example implementation using the project

Documentation:          # Developer documentation
  - Docs.md             # Project documentation
  - Tutorials:          # Tutorials for using the app

# Notes
- Organize files logically into respective folders based on MVC or MVVM architecture.
- Ensure all resources are in `Resources`.
- Follow naming conventions and avoid file duplication.
- Unit tests mirror the structure of the `Sources` folder.

But, back to my Airbyte + Streamlit app. Now that I have my rules file created, all I need to do is write a simple prompt and let AI do the work

create a streamlit app that connects to my airbyte cloud workspace and 
lists available connections, and let's me click on them to show the stream available.

As you can see, the code gets generated, and composer gives me a run down of the rules that it has followed to create it. I honestly don't know how I ever lived without it. Rules files are a game changer for developers and prompts.

Learning VisionPro: Let's Build a Stock Market App

Quinton — Mon, 01 Jul 2024 19:31:16 +0000

I’ve spent most of my career in Developer Relations and consider myself an Apple (mostly iOS and WatchOS) dev by background. Building a Vision Pro app just made sense. And why not a stock market app? Sharing my progress in a sort of ongoing, open Dev Diary also made sense. This series isn’t going to be an end-to-end tutorial. It will be more of an experiment in progress, where I will share learnings, trial and error, and tonnes of code snippets and utilities that help other Swift developers.

Enough rambling, here we are, ready to get started…

A Swift Wrapper

I'm going to use Polygon.io to fetch market data. They have a free plan. Yay. They also have a number of client libraries that wrap the RESTful APIs. However, currently there is not one for Swift. Boo. I’ve fallen into the habit of spending too much time creating a full featured package for things like this before, but this time I really want to jump in and proof things out.

After doing some research, I also discovered Apple has a Swift-OpenAPI generator project on GitHub. Polygon provides an OpenAPI spec already. I bookmarked the Apple project and will come back to once I get the basics up and running.

Authentication

To access the APIs, you need an API key, which which you can get with the free Basic plan. Once you have it, authorization is via a Bearer token making it easy to create a simple wrapper client using Alamofire.

The first piece of data I know I am going to need is Aggregates. Generally, I’ll test the endpoint using Postman or the interactive docs just to make sure I’m seeing the payload I expect.

PolygonClient

For now, let’s create a pretty basic API client, PolygonClient.swift, to fetch data. Before we do that, we need to store the API key somewhere. I’m going to use Info.plist and add a new key named Polygon API key, which I can reference from my code.

I have to come back to this approach later and use .xcsecrets or keychain, but for now this works fine but I can't really add Info.plist to my .gitignore. Adding a todo to come back and revisit this soon.

Now I have my API key set up, I can add it to my client code

import Foundation
import Alamofire

class PolygonClient {
    static let shared = PolygonClient()
    private let baseURL = "https://api.polygon.io/v2"

    func getAPIKey() -> String {
        if let apiKey = Bundle.main.infoDictionary?["Polygon API Key"] as? String {
           return apiKey
        } else {
            print("No Polygon API key found. Add it to Info.plist")
            return ""
        }
    }
}

Let’s add the call to fetch aggregate information. You’ll notice I uppercase the symbol passed in to the function. Polygon is case sensitive on ticker symbols. That got me stuck for a while, despite it being clearly called out in the docs (yep, I'm a dev, I don't already read the docs...) Once I get the response from the server, I send it back via a Promise.

 func fetchAggregates(symbol: String, multiplier: Int, timespan: String, from: String, to: String, sort: String, completion: @escaping (Result<StockData, Error>) -> Void) {
        let headers: HTTPHeaders = [
            "Authorization": "Bearer \(getAPIKey())"
        ]

         let endpointURI = "/aggs/ticker"

        //polygon is case sensitive re ticker symbols. Always uppercase, just in case
        let aggsurl = baseURL + endpointURI+"/\(symbol.uppercased())/range/\(multiplier)/\(timespan)/\(from)/\(to)?sort=\(sort)"


        AF.request(aggsurl, headers: headers).responseDecodable(of: StockData.self) { response in
            switch response.result {
            case .success(let stockData):
                completion(.success(stockData))
            case .failure(let error):
                completion(.failure(error))
            }
        }
    }

Strongly typed structs

Once the JSON response is returned, I’m taking advantage of Swift’s Codable protocol to dynamically map JSON elements to a strongly typed struct which I’ve creatively called StockData. It’s this struct that my app will use any time I am working with data. This decouples the API payload from my app allowing me to encapsulate changes to a single class. Right now the struct is super simple, but it is much better than peppering your app logic with JSON parsing logic which may change as a provider changes their endpoints. Creating strongly typed structs that conform to the Codable protocol is going to be really importance as I build a more fully fledged Swift wrapper for the Polygon APIs too.

import Foundation

struct StockData: Codable{
    let results: [StockResult]


    struct StockResult: Codable, Identifiable  {
        let id = UUID()
        let t: Double //polygon returns a universal date format.
        let c: Double

        enum CodingKeys: String, CodingKey {
            case t = "t"
            case c = "c"
        }
    }   
}

That all looks good for right now. Pretty simple, but it's all I need.

The VisionPro app

I’m far from an expert at VisionPro. Thankfully SwiftUI works pretty universally across different platforms from MacOS, iOS, and now VisionOS. The overall plan is to have multiple floating windows for the user to interact with. The main window will be the control pane where you enter a ticker symbol and adjust criteria like date ranges and submit your request to return the results in a chart. Then, to the side, I wanted to experiment with ancillary information like company news.

Exciting huh? It’s an iterative process. I want to use this project as a learning tool. My thought was to really take advantage of VisionPro’s use of space to add contextual information, and experiment with gestures to do some dynamic activities like zooming into a specific time period and have data retrieved based on that new slice of time. Enough talking, let’s get coding.

A basic ContentView

Everything in SwiftUI starts with a ContentView. My layout for the main screen is pretty typically too with a split view and few fields to accept user input.

import SwiftUI
import RealityKit
import RealityKitContent
import Charts

struct ContentView: View {
    @State private var tickerText = ""
    @State private var stockData: StockData?

var body: some View {
        NavigationSplitView {
            VStack {
                        TextField("Enter stock ticker", text: $tickerText)
                            .textFieldStyle(RoundedBorderTextFieldStyle())
                            .padding()

                        Button(action: {
                            submitAction()
                        }) {
                            Text("Submit")
                                .padding()
                                .foregroundColor(.white)
                                .cornerRadius(10)
                        }
                    }
            .navigationTitle("Polygon.io Demo")
        } detail: {
            VStack {
                //my chart will go here
            }
            .navigationTitle("Stock Information")
            .padding(10)
            .onAppear {
               //do something
            }
        }

    }

Handling button clicks and fetching data

So far so good. The sidebar let’s the user add a ticker symbol, and I hooked up a button action to submitAction() func. This is where I will call the PolygonClient we created earlier. Let’s implement this action now.


 func submitAction() {
        fetchAggregates(symbol: tickerText)
 }

private func fetchAggregates(symbol: String) {
        print("Fetching aggregates for "+symbol)

        PolygonClient.shared.fetchAggregates(symbol: symbol, multiplier: 1, timespan: "month", from: "2022-06-01", to: "2024-06-05", sort: "asc") { Result in
            switch Result {
            case .success(let data):
                DispatchQueue.main.async {
                    self.stockData = data
                }
            case .failure(let error):
                print("Error fetching stock data: \(error)")
            }
        }

    }

Generally, I try to add my actual logic separate from say a button click func. This way if I need to call the logic from somewhere else in my code, it is not tied to the UI at all. In this instance, the submitAction which is called from the button simply calls fetchAggregate, which does all the heavy lifting.

Here’s where I fetch the data and wait for the promise to return with the payload. Once I have the data, I need to map it to a chart. That’s what I’ll work on next.

Visualize the data in a bar chart

I am going to visualize the data in a pretty simple bar chart which will appear in the detail section of my split view. I already added a VStack placeholder.All I need to do is loop through the results and create a series of Bar Marks, or points, for the chart.

if let stockData = stockData {
                    Chart {
                        ForEach(stockData.results) { dataPoint in


                            BarMark(
                                x: .value("X", dataPoint.t),
                                y: .value("Y", dataPoint.c)
                            )
                        }

                    }
                    .chartYAxis {
                        AxisMarks(values: .stride(by: 20)) {

                            AxisValueLabel(format: Decimal.FormatStyle.Currency(code: "USD"))
                        }
                    }

                } else {
                    Text("Enter a stocker ticker")
                }

Looking a little wonky

If you run the app now, everything should be working great in regards to retrieving the aggregate information, but the chart looks wrong. The problem is the X axis. It looks kinda wonky. Yep, that's a technical term... The reason things look odd is that Polygon returns data with unix timestamps in milliseconds. We need to convert it to a date we can work with before binding it to the chart.

Jump back to the PolygonClient wrapper and the following helper func.

    // Polygon returns a unix timestamp in milliseconds. We need to convert this to a date before working with it.
    func convertUnixTimeToDateString(unixTime: Double) -> String {
        let date = Date(timeIntervalSince1970: unixTime / 1000)
        let dateFormatter = DateFormatter()
        dateFormatter.dateFormat = "yyyy-MM" // Specify desired date format
        let dateString = dateFormatter.string(from: date)

        return dateString
   }

Then, I can update BarMark point for the x axis like this.

 BarMark(
      x: .value("X", PolygonClient.shared.convertUnixTimeToDateString(unixTime: dataPoint.t)),
      y: .value("Y", dataPoint.c)
 )

Take two. Dewonkified!

Running the app again, everything looks much better!

Wrapping up

That’s a pretty good start. I got my client wrapper working using the Polygon.io free plan and mapping to a struct, plus created ,an albeit simple, interface to show aggregate data. I’m a long way from done, but the bones are there. Next, I’ll look at incorporating some gestures like changing date ranges via zooming, and add the company info news feed. If you want to follow along, make sure you star and watch the GitHub repo.