01 Streamlining PCB-to-CAD data transfers

This experiment is from Boris Kontorovich, Principal Systems Engineer:

Physical product development project have grown highly dependent on various digital tools. In particular, computer aided design in mechanical and electrical disciplines has become absolutely essential. Modern project development requires efficient workflows as it usually involves very frequent design iteration. One of the main pain points in this process is reliance on STEP format. It is based on several standards but its implementations vary slightly depending on software vendor. A specific issue our team has been having is moving 3D data from Altium to Creo. Electrical engineering CAD has become very good at producing highly detailed and accurate 3D model of PCB boards, but if not done properly, bringing that data into Creo becomes a problem. This is especially true when CAD comes from vendors outside our organization. In these situations, the team relied on a manual data processing method that requires several steps and relies on yet another set of CAD software.

To eliminate this problem and try to streamline the process we turned to Claude Code. We used Claude Code to first do research on background of how STEP data is organized which helped us focus on where in the data structure we need to make changes. We used Claude’s ability to analyze data by feeding it STEP files that worked properly and also ones that had problems to help zero in and verify exactly how these data structures changed. We also provided detailed descriptions of our manual workflows to Claude including all the options we used in off-the-shelf software which, again, helped Claude Code identify how to adjust STEP data.

Next, we used Claude Code to help us understand which existing libraries we could use for processing and how to set up environment to use them. Through lightweight and quick experimentation we found that only one available library out of several actually performed well enough for us to use.

The main part of the project was to try and use Claude Code to create data processing scripts that would read STEP data into a document structure and adjust it as needed. In order to test the code, we used a STEP file from one of our projects. To test the code we would process it and then try importing into Creo to see if import worked correctly. After some trial and error we found how get all the components on the board to remain in the correct position and then also we were able to preserve any color information for each surface which is helpful for visualizations. This iterative process was done locally by setting up a virtual environment using Yaml and Conda.

Once the processing Code was done, we then used Claude Code to create a docker container which would allow this application to be deployed on any standard cloud platform.

If you want to try it, below are the links for the application and the repository.

02 Automating expense report filing

This experiment is from Bryce Copenhaver, Associate Engineering Director:

I seem to be alone at Smart in my disdain for doing expense reports.

Every reporting cycle I’d sit with a pile of receipt screenshots and PDFs, review each one for the vendor, date, and amount, rename the files, match everything to the right project charge code, then manually enter them all into our official online expense system. An hour plus of mind-numbing data entry that felt like it should already be automated. So I started poking at it.

The idea was simple: point it at a folder of receipts, let it read each one, and get back cleanly renamed files, a CSV, and a copy-paste-ready expense email. In addition to these outputs, I wanted to find a way to automatically submit these to our expense system, plus a way to reconcile everything against my personal finance app so nothing slips through.

Two things I really wanted to explore along the way:
I didn’t want it to cost anything to run. A tool for saving myself busywork shouldn’t come with a monthly bill. So it can run completely free and local: OCR with Tesseract, or a local model through Ollama, and only reach for paid options like Claude or Gemini if I ever want to compare accuracy on a messy receipt.

I wanted to play with the latest OCR / vision models coming out of Hugging Face. Half the fun was wiring up the best open models (things like MiniCPM-V, Granite-Vision, InternVL2) through the Hugging Face API and putting them head-to-head on real receipts to see which actually reads a crumpled coffee receipt best. Every backend returns the same shape, so swapping one in and testing it is trivial.

This was also a fantastic opportunity to try something new. I’d never really written JavaScript before this. I came in knowing the problem I wanted to solve but not the language. Along the way I learned Node.js, how a web server handles uploads and streams results back live, how to work with a handful of different APIs, and how to keep data persistent so I can close the server and pick up later. Leaning on an AI coding assistant meant I could learn by working on something I actually cared about, instead of grinding through tutorials.

Then, after a few days of building this and excitedly telling coworkers about my expense-report breakthrough, I slowly realized I was one of the only people at Smart who actually had this problem. Turns out most Smarties just… submit their expenses and move on. Oh well, at least now I have an amazing tool that will save me hours after work travel trips.

My biggest takeaway: you don’t need to be an expert in the tech to experiment your way to something useful. A problem worth solving, even a problem only you seem to have, and a bit of curiosity goes a long way.

03 Simplifying the planning poker experience

This experiment is from Carter Parks, Machine Learning Architect:

Planning poker helps software teams align on effort and uncover uncertainty before work begins. But in remote meetings, the process is often surprisingly clunky. Team members count down in Zoom chat, trying to reveal their estimates simultaneously, only for someone to submit too early or too late, disrupting the exercise.

To simplify the experience, I built AgileAnte as a rapid experiment using Claude Code. The app provides a real-time planning poker experience, leveraging Next.js and Cloudflare’s PartyKit to synchronize votes instantly. Beyond solving a small workflow frustration, the project was an opportunity to explore how quickly AI-assisted development can help evaluate new technologies and assemble the right technical stack for a working prototype.

AgileAnte is open source and can be self-hosted with a JIRA API key, making it easy for teams to integrate into their existing planning process. Future iterations could include native Zoom integration and JIRA OAuth to further streamline adoption, but even as an experiment it demonstrates how quickly practical tools can emerge from a simple idea and the right AI-assisted workflow.

Take a look at the README.md to get started: https://github.com/carter/agileante

04 Alternate side parking tracker

This experiment is from Jehan Diaz, Systems Engineer:

Anyone who keeps a car in NYC knows the alternate side parking rhythm: street sweepers come through twice a week, and you have to be on the right side of the road at the right hour or you’re looking at an expensive ticket. The schedule is posted on signs up and down every block, but keeping track of it is a persistent tax on your attention. It gets messier when a group shares one car and nobody’s quite sure where it ended up.

I built ParkShare to alleviate this mental burden. Using Anthropic’s Claude Code, I put together a working prototype in a few days to share with my roommates, using frameworks and languages I had never touched before. Claude handled most of the syntax and dependencies, but getting to a working app involved building off my own design and architecture ideas with lots of manual cleanup. I had to work in both supervisory and antagonistic roles with the agents.

Here’s how the app works: when someone parks, the app reads the device’s location via the browser Geolocation API, drops a pin, and reverse-geocodes the coordinates into a street address. From there it queries the New York City Department of Transportation’s “Parking Regulation Locations and Signs” dataset to pull the sanitation rules for that exact block, and parses the sign text into structured cleaning windows. Precise geolocation comes up a lot in what we build at Smart Design, so a problem that lives or dies on it felt like a natural fit.

The app also handles the group coordination side. Anyone driving the car can subscribe to it, so the whole group tracks the same vehicle. When one person moves it, the new location is immediately available to everyone. Alerts go out via the Web Push API even when the app is closed, and it reads the city’s holiday suspension calendar so nobody gets a nudge on a day the rules are paused.

You can read more about this short experiment in the repo documentation, demo it yourself (https://alternate-side-parking-tracker.vercel.app/login), and build on it here: https://github.com/jehandiazc/alternate-side-parking-tracker! The tool will be up for testing through for a short time, and currently leans on free-tier services, so please excuse any slow performance.

05 Automating project update slides

This experiment is from Tyler Sanborn, Technical Project Manager:

Engineering teams produce a meaningful volume of internal communication every week: standups, sprint planning, and demos. The underlying work is happening regardless. The question that concerned me was whether the artifact of that work, presented as slides, needed to take additional time away from the engineering teams.

Engineers know what they’ve built, do they really need to do slides? For a team of our size, it is a considerable cost when tallying time.

The system built here addresses that gap through two integrations: Slack and Zoom. A team member posts a raw update to the project Slack channel as informal text, attached screenshots, or a photo of a prototype. The tagged bot receives that message, passes the content to Claude Opus, and returns a structured slide: an outcome-led title, bullet or paragraph copy, and images placed in a defined zone at the correct aspect ratios. A layout QA loop applies the result to a staging deck, fetches a real thumbnail from the Google Slides API, and grades placement before a human ever reviews it. A more robust look at evals in a similar context was recently shared here via Anthropic: https://www.youtube.com/watch?v=v9FTCvkV_a0

If the post began in Slack, the admin sees a preview there, reacts with a checkmark, and the slide is live. The demo video shows a more automatic slide generation from Zoom.

The Zoom path closes the loop on meetings. A bot leveraging Recall.ai joins the call, captures the speaker-attributed transcript, and returns a recording when the session ends. Speaker diarization is the attribution of each transcript segment to the person who said it, and recall.ai handles that natively through Zoom’s caption system. The system extracts still frames from screenshare intervals using ffmpeg (obviously) and routes each speaker’s content through the same Claude design pipeline that processes Slack submissions. When the meeting ends, the slides are already being written.

We’re aiming for passive artifact generation here. A passive artifact is one produced as a byproduct of work already happening, not as a dedicated documentation task. When an engineer posts a Slack update, they are going to write that message regardless. When the team presents in a Zoom standup, that meeting was already on the calendar. The slide is generated from those existing moments and formatted at zero additional cost to the person who created the underlying work.

The QA loop catches layout errors automatically, up to three revision attempts, before anything surfaces to a human. A five-person standup produces five reviewed slides in roughly the time the meeting takes to end.

Documentation overhead on engineering teams tends to grow quietly until it becomes a meaningful drag on output. This system begins to address that by treating communication as something that happens alongside the work, and letting the artifact flow from it.

PS: Yes, I used Gemini for the thumbnail generation for this Claude project!

06 Aggregating relevant industry articles

This experiment is from John Anderson, Partner and Executive Technology Director:

In my 20+ year career, I have learned countless programming languages, platforms, and infrastructures that are now obsolete, replaced by newer languages and systems. I still prefer ActionScript 3.0 over Objective C, but I digress.

As a computer programmer, keeping up with technology was not just part of my job, it was my livelihood. It was completely normal to spend a month jumping between JavaScript, C, Python, and Swift. Learning new tools was simply part of the job.

Today, my role at Smart Design looks very different. I have gone from being an individual contributor to helping identify technology trends and predict where the industry is headed. The challenge is that I no longer have the time to gain hands on experience with every new advancement our technology team is exploring across software, hardware, and ML and AI.

So I built a tool using Anthropic’s Claude Code to help bridge that gap.

Every morning it gathers the most relevant news from hardware, Edge AI, manufacturing, consumer electronics, research publications, GitHub, and, of course, Reddit. It then cross references those stories against the work we are doing at Smart Design and curates the three articles that are most relevant to our team.

It has become a simple way to stay informed without trying to read everything. Instead of spending hours sorting through information, I can quickly understand what matters, why it matters, and how it connects to the work we are doing.