If you're talking about from the very beginning, and note that very few major game engines are coded from scratch anymore, and note that this is an example and not necessarily how it always works . . .
Start by rendering a flat-shaded cube. Add basic lighting effects to it. Add a way to move the camera around. Now you can fly around a boring cube, suspended in an infinite black void. Yay.
Next, you probably want to import a model. At the very least, your artist can whip up a demo model (a teapot is surprisingly traditional), but they may have an actual game model they can hand you. Again, we're sticking with flat shading for now, so it'll show up looking like it's made out of . . . well, no realistic substance, but sort of a cross between matte plastic and porcelain. This, but without good lighting. And we're still at the point where it's completely unmoving.
The next three major steps can be done in any order.
First, you'll want terrain. Most modern games divide rendering into "static geometry" and "actors", where static geometry include things that don't change (walls, ground, lampposts) and actors include things that do change (players, vehicles, destructible lampposts.) While the basic rendering concept is the same for both, there are optimizations you can do for static geometry that you can't do for actors. You'll need terrain for the gameplay engineers to really get going, so if they're waiting on you, it's time to rig up at least basic terrain rendering.
Second, you'll want texturing. This is a huge subject and chances are you'll be getting to a milestone, going to do something else more critical, then coming back to it, repeatedly. Your first pass may simply add textures to the model. Your second pass may add improved lighting and surface behavior. Your third pass may add shadows (I could fill an entire response talking about shadows). Depending on what kind of a game you're doing, this can get arbitrarily complicated. Somewhere in here you may also switch your entire game engine to deferred rendering.
Third, you'll want animation. Your animators (assuming you're not living in 1995) will have set up animation rigs for their models, consisting of bones running through the model and information about how the bones move during certain animations. You'll probably start with the ability to play animations on demand, then add the ability to mix animations together.
Once all of that is done, it's time to work on compatibility. If you're working on a AAA game then you have some way to test your code on many different kinds of hardware - maybe it's inhouse, maybe you contract out to a testing firm, whatever. A lot of your code will break on specific graphics cards or specific driver versions, and you get to fix as many as you can.
It's also time to consider optimization. Rendering is a big, big speed issue, so now you have to figure out how to exploit the hardware at the deepest level in order to run as fast as possible. If you think this may conflict with "compatibility", you're right! It totally does! The best optimizations, you'll find, will just flat-out not work on some cards. You get to balance all these factors.
Around this point, your artists will be demanding new texturing tools or new animation features, and your level designers will want new terrain rendering techniques. Go back to "the next three major steps can be done in any order" and repeat until the game is done.
I'm going to skip the parts that aren't terribly visually noticable. First, you sorta have to wait until terrain rendering is in, although there's a lot of backend stuff you can do until then.
Once you've got that, you'll set up some basic collisions. This will likely take the form of flying to a location in-game then pushing a button that drops a cube. The cube falls and hits the ground. Once the cube lands on the ground consistently, you can start setting up player movement, so you can run around the world in the same way as a player does.
Once you've got basic movement physics working, you're in one of those "these can be done simultaneously" segments again:
Combat needs to be implemented. You need things that can shoot things at things, and all those things need to behave appropriately.
Physics needs to be implemented. You've got collisions working, but collisions are just a small segment of physics. When someone ramps a jeep off a tank, everything needs to behave roughly as intended.
Game mechanics need to be implemented. How do you know when you've won or lost? How often do things spawn, and what controls that? If the Communists conquer a spawn point, why does it keep spawning Anarchist vehicles? That sort of thing.
All of these can take, again, arbitrary time, based on how much stuff your designers want you to do. You'll also be spending a ton of time tracking down bugs ("hey, look what happens when I drive a tank onto this jet fighter's wing"). Note that a good deal of this will happen with an untextured world, or with models running around in the character rig position, or with tanks that are just large boxes with the word "TANK" clumsily spraypainted on.
UI can actually start before the main rendering code goes in, since UI and game-world rendering tend to use totally different codepaths. Instead of starting with a cube, you'll start with a box, then add textures to the box, then add text to the box.
At this point, your life is spent trying to get enough time to write general-purpose widgets, while still putting in enough UI time that the designers and game mechanics developers can test the game in a vague semblance of realism. At some point your UI artists will come up with a consistent feel for the UI, and then you'll start work on the finalized UI elements, while testing those UI elements on actual players to ensure that they're understandable and usable.
I can talk more about these as needed, but it'll turn into a megaresponse if I do, so for now, I won't :)