Reading from Flash is little Endian style

Suppose  You have a hex line as show below
     : 10 0000 00 0C9434000C944F000C944F00 4F

The machine instruction 940C is saved in the .hex file as 0C94 ok

CODE:  in hex file
0x0000: 0C
0x0001: 94
0x0002: 34
0x0003: 00
0x0004: 0C
0x0005: 94
0x0006: 4F
0x0007: 00
0x0008: 0C
0x0009: 94
0x000A: 4F
0x000B: 00

How ever when you switch on the power to an avr it makes 16bit opcode fetch which is little- endian. Finally it reads the code in:
0x0000  : 0c
0x0001  : 94

as 0x940C  and passes it to the instruction decoder which identifies it as a jump op code . This again  make a second fetch as part of this same opcode this time it picks up

0x0002  :  34
0x0003  :  00

which again it reads as little endian and therefore treats as WORD address 0x0034 (which is BYTE address 0x0068). So after reading the first 4 bytes in two 16 bits chunk it has determined it has "JMP 0x0068" and sets PC to be that address. (really 0x0034 in fact - it's just GCC that interprets things byte wise to be common across all architectures).

So, the bytes are programmed in exactly the order they appear in the .hex at increasing byte addresses but when the AVR core makes fetches (two bytes, 16bits at a time it treats them as  little endian using the lower addressed of the two bytes as the lower part of each 16bit fetch. So it's not when programming hex that little endian ness comes into play - it's when the data/code is later fetched back from the flash that the endianness issue applies.

So, finally you can say that data or code is fetched in little endian model.