The surprising thing about adding video generation to apLabs was how quickly it worked once the groundwork was already in place.
That is an important distinction. AI-assisted software development can look almost magical from the outside, especially when a new feature appears in a morning. But the speed does not come from nowhere. It comes from earlier architectural decisions, reusable patterns, clear boundaries, and enough discipline to avoid turning a useful system into a pile of disconnected experiments.
This article is a short account of adding video generation to apLabs, why I wanted the capability, how I approached it, and what the exercise taught me about building practical AI-enabled software.
Why Video Became Worth Exploring
The immediate reason was practical. I have been working on marketing initiatives around apLabs and Technical Leaders, and video is becoming harder to ignore.
Many website visitors no longer want to read long explanations before they understand the basic point. That creates a problem for technical businesses. If the message is too long, people do not engage. If the message is too short, the nuance disappears.
Video can help with this. A short clip can show context, mood, product use, or a workplace situation faster than text alone. For software products, especially, a well-crafted video can communicate what the product is about before the visitor has committed to reading a longer page.
The alternative was to subscribe to stock video libraries. That may be appropriate in some cases, but it has two obvious limitations: cost and choice. You pay for access, and then still have to work within whatever material happens to exist. For niche industrial and software themes, that can become frustrating quite quickly.
So the experiment was simple: could apLabs generate short, reusable video assets in the same way it already generated images?
The Advantage of an Existing Pattern
apLabs already had an image generation feature. The user could define parameters, submit a request, and the system would call an external image generation model through an API.
An API, or application programming interface, is simply a structured way for one software system to request a service from another. In this case, apLabs sends the prompt and settings to an AI model, waits for the result, and then stores the generated file and its metadata.
The existing image generation architecture already handled several important things:
- accepting user-defined generation settings;
- calling the external AI service;
- processing the result in a backend worker service;
- storing the generated file in Amazon S3;
- saving metadata in MongoDB;
- presenting the item back to the user in a library interface.
That meant video generation did not have to be designed from scratch. The architectural question became: can the video feature follow the same pattern as images, with the necessary changes for video-specific parameters?
This is where the earlier groundwork paid off. Once a software system has a clear internal pattern, adding a feature becomes less about invention and more about specification. I could ask the coding agents in Visual Studio Code to study the existing image generation structure and implement video generation in a similar way.
An AI coding agent is an assistant that can read parts of the codebase, propose changes, generate code, and help resolve errors. It does not remove the need for judgement, but it can dramatically compress the mechanical work when the developer can describe the requirement clearly.
Choosing the Video Generation Approach
For this first version, I explored Google’s Veo video generation models through the Gemini and Vertex AI ecosystem. Veo is Google’s AI video generation family, capable of generating short video clips from text prompts and, depending on the model and interface, other inputs.
The important point here is not that one vendor is “the answer”. In fact, one of the lessons from this exercise is the opposite. AI model availability, pricing, performance, and product direction can change quickly. For developers and architects, that is a warning against building too tightly around any single model provider.
The better approach is to design the application so that the business feature — in this case, “generate a short video from a structured brief” — is separated from the specific vendor used behind the scenes.
In apLabs, the video generation feature is therefore better thought of as a capability, not as a permanent commitment to one model.
What Makes Video Different From Images
At first glance, video generation looks like image generation with movement. In practice, it needs more structure.
An image prompt can often be relatively compact. A video prompt has to describe more than the subject. It needs to describe motion, camera behaviour, setting, pacing, and sometimes continuity between characters and environments.
For the apLabs video feature, I added structured parameters such as:
- brand specification — the visual style, tone, colours, formality, and overall feel;
- character specification — who appears in the video, including role, age profile, dress, and visible context;
- environment — whether the scene is in a corporate office, factory floor, workshop, plant environment, or another setting;
- motion style — for example, slow cinematic movement, gentle zoom, panning, or faster motion;
- model selection — allowing different video generation models or variants to be selected;
- aspect ratio — landscape or portrait, depending on where the video will be used;
- resolution — such as 720p, 1080p, or higher where supported;
- duration — constrained by the limits of the chosen model.
These parameters are a way of turning a vague creative request into a repeatable generation profile.
The metadata is stored in MongoDB, and the generated video is treated as a first-class library item in apLabs, alongside other knowledge assets such as images, notes, conversations, and documents.
Prompting Matters More When Mistakes Are Expensive
One of the first test prompts asked for factory workers leaving a factory through a turnstile. In my mind, I was picturing a one-person-at-a-time industrial turnstile — almost like a rotating cage entry system.
The generated result interpreted the turnstile differently. It produced something closer to airport or train terminal turnstiles placed into a factory environment. Technically, the model had followed the word “turnstile”. Practically, it had missed the industrial context.
That was a useful reminder. With text generation, a weak output can often be revised quickly. With video generation, each attempt costs more time and usually more money. The opportunity for casual trial and error is much smaller.
So video prompting needs more discipline. It is not enough to say “factory turnstile” and hope the model understands the intended industrial object. The prompt may need to describe the physical equipment, the type of access control, the worker flow, the plant environment, the camera angle, and what should not appear.
For technical and industrial use cases, this matters. The model may be visually impressive while still getting important contextual details wrong.
A Small Bug, Quickly Fixed
The implementation was not completely error-free, but the one error was straightforward. An API call failed because a value had been passed as a string when the API expected a number.
In older development workflows, that sort of bug might involve searching through documentation, tracing the call, changing the type, recompiling, and retesting. In this case, I took the error message, gave it to the coding agent, explained the type mismatch, and asked it to correct the call.
A few seconds later, the problem was fixed.
This is a small example, but it captures where AI-assisted development is genuinely useful. It does not replace architectural thinking. It does not decide what the feature should mean. But it can remove a lot of friction from routine implementation and debugging.
The Real Lesson: Architecture First, Acceleration Second
The temptation with AI development tools is to start with the agent and hope the application emerges. That may work for a prototype, but it is a risky way to build a serious system.
The more useful pattern is the reverse:
- establish the architecture;
- define clear entities and boundaries;
- build reusable patterns;
- use AI coding tools to extend those patterns quickly;
- keep human judgement in control of design decisions.
That is what made this video feature feasible in a short time. The worker service pattern already existed. The S3 storage pattern already existed. The MongoDB metadata pattern already existed. The library presentation pattern already existed. The coding agent could follow the road because the road was already there.
This is also why vendor independence matters. If the video generation provider changes pricing, model names, duration limits, or strategic direction, the application should not collapse. The system should be able to adapt by changing the integration layer rather than rewriting the whole feature.
Practical Implications for Technical Leaders
For engineers, software developers, and business leaders considering similar AI-enabled features, I would draw a few practical conclusions.
First, do not confuse a working demo with a sustainable capability. The demo proves possibility. The architecture determines whether it becomes useful.
Second, put metadata and workflow around generated content. A video file without context is just another asset to lose. A video with a profile, prompt, parameters, storage location, and usage notes becomes part of a managed knowledge system.
Third, design prompts as reusable specifications, not throwaway sentences. This is especially important where the content must reflect industrial reality rather than generic visual imagination.
Fourth, avoid locking the business process too tightly to one AI provider. The model landscape is still moving. Your application should preserve optionality.
Finally, treat AI coding agents as accelerators, not architects. They are very good at following patterns. They are less reliable when the pattern itself has not been thought through.
Conclusion
Adding video generation to apLabs was a small feature in one sense, but it clarified several larger points.
The value was not simply that a video could be generated. The value was that apLabs could absorb a new media type by reusing existing architecture, extending the library concept, and keeping the generated asset connected to its metadata and purpose.
That is the kind of AI development that interests me most: not spectacular demos, but practical capability added to a system that is gradually becoming more useful.
The lesson for technical leaders is straightforward. AI can shorten development cycles dramatically, but only when combined with sound architecture, clear intent, and disciplined specification. Without those, speed simply helps you create confusion faster.
Call to Action
If you are exploring AI, automation, or software tools for industrial work, look beyond the demo. Ask how the capability will be structured, governed, reused, and adapted when the technology changes. Follow the Technical Leaders and apLabs journey for more practical notes from the build process.
References
- Google AI for Developers. “Generate videos with Veo.” Google Gemini API documentation. https://ai.google.dev/gemini-api/docs/video
- Google Cloud. “Generate videos using Veo on Vertex AI.” Vertex AI Generative AI documentation. https://cloud.google.com/vertex-ai/generative-ai/docs/video/generate-videos
