↓Skip to main content

Two Weeks with GPT-5 Codex

·5 mins

Over the past two weeks, I’ve been working regularly with GPT-5 Codex to explore its capabilities. After the initial glitch, I’ve experienced consistently impressive results with Codex that I wanted to share.

Challenge: Cutting Rectangles #

One of the first challenges I presented to Codex was implementing an algorithm to cut and merge “snapping regions” in my Fancy Tiles Linux Mint extension. This tool allows you to create flexible, irregular layout regions on your screen. When moving application windows, you can snap them into these regions. This is similar to Fancy Zones in Windows, and particularly useful for large monitors.

The pending feature request was to enable merging two regions into a single larger region for window snapping. This wouldn’t be particularly challenging if the layout were always a regular n×n grid, but that’s not the case. The layout can be highly flexible, with dividing rows and columns that don’t align. The video below demonstrates this complexity:

As you can see, merging regions sometimes results in a ‘cut’ in another region. Either along the edge or just intersecting with a single corner. This last scenario is particularly tricky: you transition from a easy rectangle with four points to a polygon with five points. Additionally, you must handle both outer and inner arcs for the rounded borders.

I had already attempted this with Claude Code, which struggled with the arc calculations, so I turned to Codex with this request:

In @drawing.js at line 31 the function drawRoundedRect() currently draws a rounded rectangle based on the rect parameter. However, I want it to draw the shape of the rect with the SUBTRACTION (exclusion) of the excludedRect. The excludedRect partially overlaps with the rect, but is never fully contained within it.

First create the algorithm to get the list of points along the path when the excludedRect is subtracted from the rect. Then draw this path by adding lines between all points. DO NOT USE the arcs, we will add that later. There should be a single path, starting and ending at the same point. This path can then be filled.

Think very hard before implementing this.       

Codex worked on the problem and responded:

Replaced the rounded-rect drawing with a polygon path that subtracts the overlap from excludedRect, so the fill/stroke now follows a single straight-segment loop.

- drawing.js:26-242 Added utilities to quantize coordinates, compute the rect/exclusion intersection, partition the area into cells, cull internal edges, and trace the largest remaining loop to generate the vertex list for the subtraction path.                
- drawing.js:245-261 Rewired drawRoundedRect to reuse the generated vertices, creating the path with moveTo/lineTo only and skipping work when no area remains.  

Verified the module loads via node -e "require('./drawing.js')"; you can also run the extension to confirm the new outline looks right. Next up, you might (1) add the rounded corner logic back on top of this polygon or (2) tighten tests around tricky overlap shapes. 

The result was perfect on the first attempt, completing in just a minute or two! It handled all cases flawlessly. Both cutting edges and managing single-corner scenarios. What impressed me most was Codex’s ability to infer the underlying concepts from my somewhat vague description and apply robust polygon construction methods. You can see the code here. The ~200 lines of code would have taken me considerably longer than two minutes to write, and the result is both readable and maintenable.

While Claude Code (Sonnet) approached this by modifying the original rectangle data with numerous if/else statements for edge case detection, Codex stepped back and selected the right data structures and algorithms. This is exactly what an experienced software engineer would do after writing 80 lines of branching code and recognizing the need for a better approach. Codex built the proper abstraction (polygons) to handle this feature elegantly, which I find quite impressive.

I then asked it to restore the rounded borders:

Now add the arcs back so we get nice rounded corners. Use arcs on both the outside corners AND the inside corners.          

Codex responded with:

Reworked the path-building inside drawRoundedRect so the polygon now stays CCW, trims each edge by the requested radius, and swaps between arc/arcNegative based on the corner’s turn. That gives rounded treatment to both convex outer corners and concave inner notches, while falling back to straight joins when an edge is too short (drawing.js:265-330). Confirmed the module still loads with node. You might want to eyeball the rendered layout or run your usual drawing preview to ensure the curves match expectations.    

Once again, it worked perfectly. Notably, it recognized that arcs wouldn’t fit on very short edges and implemented a fallback to straight joins. These kinds of details distinguish average software from great software, and I never even specified this requirement.

More broadly, my experience with coding agents so far has shown they excel at adding code and complexity but struggle with removing code and reducing complexity. Since reducing complexity is crucial for long-term maintainability, it’s refreshing to see Codex demonstrate this capability multiple times over the past weeks.

Beyond this feature, I’ve used Codex to create a small but fully functional flight search application using Svelte as the frontend framework, along with numerous Python and Bash scripts ranging from renaming Hyprland workspaces to PDF invoice generation for my business. Most worked on the first attempt. It’s no exaggeration to say that for these specific small-scale projects, working with Codex made me deliver functionality 2-3 times faster than working without a coding agent. That’s a very significant improvement.

Conclusion #

Overall, I’m impressed with Codex’s (GPT-5) code quality, particularly its ability to generate clean, readable code and reduce complexity where appropriate. The code feels more structured and thoughtful compared to Sonnet 4, though this is admittedly difficult to quantify. Claude Code has recently released their Sonnet 4.5 model, so I’m sure they’ll continue to improve as well. For now, I recommend continuing to experiment and switching between models when you feel one isn’t making proper progress on a particular feature.