From Manual Repetition to Intelligent Automation: A 3-Year Pre-Press Journey
The Problem
Every production facility has its version of the same story: a task that takes far too long, done the same way every day, by someone who knows exactly how painful it is but has no path to change it.
Ours was pre-press template preparation. Every job that came through — signage, print runs, custom fabrication — required setting up production-ready files from scratch. Adjusting dimensions, applying brand guidelines, placing cut lines, exporting formats for each machine. A single template: 30 to 45 minutes. Multiply that by 15 to 20 jobs a day and you have a full-time job that produces nothing but repetition.
The cost wasn't just time. It was attention. Every hour spent on mechanical reproduction was an hour not spent on catching problems, improving quality, or thinking about better processes. The floor kept moving. Pre-press kept repeating.
Year One: Starting the Conversation with AI
In early 2023, the first experiments began — not with code, but with conversation. ChatGPT had just reached wide availability, and the initial question was simple: could it help think through a better approach to template generation?
The answer was yes, but not in the way expected. AI couldn't automate Photoshop directly. What it could do was accelerate the thinking. Describing the problem, explaining the constraints, asking "what would you do?" produced real starting points: Photoshop Actions, scripting via ExtendScript, batch processing possibilities.
This became the methodology for everything that followed: use AI not to write the final solution, but to compress the research phase. A problem that might take a week of documentation reading to understand could be framed, explored, and validated in a day.
The first working tool was a Photoshop Action sequence. Recorded, parametrised, triggered from a panel. It handled the most common template type — reducing that job from 35 minutes to around 12. Not transformative yet, but proof the direction was right.
Year Two: Illustrator and the Extension Approach
Photoshop solved part of the problem. But a significant portion of pre-press work lived in Illustrator — vector files, cut paths, multi-layer exports. Actions didn't translate. A different approach was needed.
The second year focused on building an Illustrator extension using the UXP framework. This was a harder problem: a proper interface, persistent settings, multi-step automation triggered by user input. The extension allowed operators to select a job type, input dimensions, and generate a correctly-structured document with guides, cut lines, bleed zones, and export presets — in under 8 minutes.
What made this phase work was the same iterative loop: build a small piece, test it on real production jobs, identify the friction, bring that specific friction back to AI-assisted problem solving. Not "build everything at once" but "make this one thing work, then the next thing."
The AI contribution shifted during this phase. Year one was about understanding what was possible. Year two was about implementation details — handling edge cases in Illustrator's scripting API, dealing with unit conversion between document types, managing export profiles across different machine requirements.
By the end of year two, the two tools together covered roughly 70% of daily template volume. The remaining 30% were complex or non-standard jobs that still required manual work.
Year Three: Consolidation and the Shift to Python
The third phase wasn't about building new tools — it was about making the existing ones sustainable and extending the coverage.
The Photoshop and Illustrator tools were consolidated into a single workflow trigger. Operators no longer needed to choose which tool to open. Job type detection — based on file format, dimensions, and a simple tagging system — routed work to the right automation automatically.
Python entered the picture for tasks that neither application handled well: file renaming at scale, folder structure generation for new clients, automated preflight checking against a specification list, and report generation for production logs. These weren't glamorous problems, but they were real time sinks that the application-specific tools couldn't reach.
The AI-assisted development approach matured significantly by this point. The questions became more precise. Instead of "how do I automate this?" the framing became "here is the current implementation, here is the edge case it fails on, here are the constraints — what's the minimal change that addresses this without breaking the existing behaviour?" Faster iteration, less exploratory waste.
The Results
Three years of iteration produced measurable outcomes:
- Template preparation time: 30–45 minutes reduced to 4–6 minutes per job
- Daily time savings: 4–6 hours recovered per operator per day
- Monthly hours freed: 100+ hours reallocated from repetition to quality work
- Error rate on templated jobs: near zero (vs. occasional manual errors before)
- Coverage: approximately 85% of daily volume now runs through automation
The 15% that remains manual isn't a failure — it's a deliberate boundary. Complex custom jobs benefit from human attention. The automation handles the repeatable; people handle the exceptional.
What Actually Made This Work
The technology was not the hard part. ExtendScript, UXP, Python — these are learnable. What made the difference was something less visible:
Deep familiarity with the problem before writing any code. The first tool wasn't built until the problem was understood well enough to describe every variation of it. That knowledge — earned on the floor, not inferred from documentation — is what made the automation robust instead of fragile.
Iteration over planning. No year-long roadmap. No requirements document. Each tool was built to solve the most painful problem visible right now, tested on real jobs, and improved based on what actually broke. The scope stayed small until something worked, then expanded.
AI as a research accelerator, not a code generator. The most valuable use of AI tools across three years was not generating code. It was compressing the gap between "I don't know how to approach this" and "I have enough understanding to try something." That gap, multiplied across dozens of small technical problems, would have stalled the project entirely.
The Broader Pattern
This project is not unusual in its structure. Most manufacturing environments have equivalent problems: processes that are slow because they've always been slow, knowledge that lives in one person's head, repetition that nobody has had the time or mandate to address.
What's changed is the cost of addressing them. Three years ago, building a custom Illustrator extension required either deep expertise or significant budget. Today, with AI-assisted development, the iteration loop is fast enough that someone with domain knowledge and willingness to experiment can build real tools — without a computer science background.
The floor doesn't need perfect software. It needs software that solves the right problem, reliably, without creating new ones. That's a lower bar than most people assume, and a more achievable one than it used to be.
More articles
Why Your Manufacturing Software Fails Without Offline-First Design
Cloud-only applications fail on the factory floor. Learn why offline-first architecture is critical for manufacturing software.
The True Cost of Manual Shop Floor Data Entry
Manual data entry on the factory floor wastes time, introduces errors, and obscures cost. Calculate the real impact.