From AI-assisted development to AI-driven implementation
GeoForm has been built with AI support from the very beginning. We used it for brainstorming product ideas, refining architecture, generating code (always reviewed), and reviewing human-written code. This gave us a noticeable speed-up, but still felt like an extension of normal development.
At the beginning of 2026, something changed. The signal around AI coding agents became too strong to ignore. In February, we extended our workflow with the Codex toolset and started treating AI not just as support, but as part of implementation.
This article is a practical breakdown of how that works in reality—not in demos, but in actual feature delivery. As a reference point, we’ll use a feature where user input is parsed with the OpenAI API and used to generate a map dynamically.
What you will not find below
This is not a guide to Codex itself. We are not covering commands, setup, pricing, or deployment pipelines. The focus is simpler and more important: what kind of process makes AI-assisted development actually work.
Codex Overview
The easiest mistake to make is to think about Codex as a single tool. It’s not. It’s much closer to a small ecosystem.
In practice, there are three moving parts:
- Codex CLI — where structured, step-by-step implementation happens
- IDE extension — useful for smaller edits and local iteration
- GitHub integration — where PR reviews become a key control point
This setup works particularly well when combined with ChatGPT. ChatGPT is not replaced here—it becomes the place where specifications are shaped and prompts are prepared, while Codex executes against that structure.
This distinction matters, because it leads to a different way of thinking about development. AI-driven development is not just “faster coding”. It’s a different mode of working. And the key idea is simple:
AI does not replace engineering discipline. It amplifies it.
- Good process → faster, higher-quality output
- Weak process → faster accumulation of problems
That’s why “vibe coding” often feels productive in the first hour and painful shortly after. There’s no structure to amplify.
Workflow (Pre-development)
The part that matters most happens before a single line of code is written.
With Codex, starting implementation too early is a mistake. The tool performs best when the problem is clearly defined and constrained, so at GeoForm we put a lot of weight on pre-development structure. The workflow is simple on paper, but strict in practice.
It starts with a Product Requirements Document. This is where we define what we are actually building and what constraints matter. Nothing fancy, but it forces clarity. The document is drafted and then refined with ChatGPT until it is clean, consistent, and readable.
From there, we move to the Technical Specification. This is where architecture decisions are made—how the system fits together, how data flows, where integrations happen. Again, the process is iterative: draft, refine with ChatGPT, finalize in markdown.
Finally, we create the Implementation Plan. This is where things become executable. The plan breaks the work into tasks, captures design-level decisions, and provides a structure that Codex can actually follow.
If you zoom out, the flow is very simple and not unprecedented in development workflows before the introduction of AI assistants:
- PRD → defines what
- Tech Spec → defines how
- Implementation Plan → defines execution
Each step’s outcome is documented in a markdown file, stored in the repository, and feeds into the next step. Nothing is created in isolation.
Over time, markdown naturally becomes the shared language across all of this—simple, versionable, and easy to pass between tools.
Is this overkill? For quick prototypes, probably yes. But for production work, this structure adds value even without AI. With AI, it becomes the difference between leverage and chaos.
Development (with Codex)
Once the specifications are ready, development moves to Codex CLI—but even here, the first step is not coding.
We start by aligning the specifications with reality. The PRD and Technical Specification are provided to Codex, which reviews them against the existing codebase. This often surfaces inconsistencies or forces clarification early, sometimes leading to small updates in the implementation plan.
Only after this alignment do we begin implementation.
From that point on, the process is highly iterative. The loop is simple: take a task, ask Codex to implement it, review the changes, adjust, and decide whether to commit and move forward. This repeats throughout the feature.
In practice, this feels closer to tight pair programming than automation.
Most interactions follow a few recurring patterns:
- Codex hits a blocker and asks a precise question
- It proposes a design—but you make the call
- It generates code—but every diff must be reviewed
- It breaks something—and sometimes helps fix it
Continuous review is critical—not just to catch issues, but to stay in control of the system.
A few practices become essential in this mode of development.
First, slicing work much thinner than usual. Instead of building a feature in one go, we aim for small increments—small PRs, small deployable steps:
- reach production in 2–3 iterations
- keep everything behind a feature flag
Second, controlling commits explicitly. Codex will accumulate changes unless you decide when and what to commit.
Third, resolving blockers as they appear rather than over-planning. Letting Codex attempt implementation, fail, and ask questions often leads to better decisions.
Finally, keeping the feedback loop tight. The closer this feels to real-time collaboration, the better the results.
The weakest part of this process is not technical—it’s unclear input. When UX or product requirements are vague, results degrade quickly. Most failures are not caused by the tool, but by the quality of the specification.
Conclusions
The speed gains are real. For the feature described here, it took roughly:
- ~2 hours to produce the full specification (PRD, Technical Spec, Implementation Plan)
- ~4 hours to implement, including deployment, manual testing and a few refinement loops to tighten things up
That is fast—but it’s not magic.
The biggest misconception around AI-assisted development is that it allows you to jump from idea to production-ready system in hours. In practice, that only works if the structure is already in place.
Codex does not replace engineering. It amplifies it. And that amplification is unforgiving—good practices become more powerful, and bad practices become more visible.
If there is one takeaway from this, it’s this:
Structured development + AI = leverage
Unstructured development + AI = chaos, just faster