Im watching the flat assembler introduction to x86, the issue is, he can debug step by step, but when i use step into or step over in the debugger, it goes back to the int3

I have this issue discussed in the video of how to use fasm with x64bdg, around 03:08 time:
https://youtu.be/7GSp-ZIMqxc?t=184

ah thank you

There is the int3 instruction incompiled into the code to be debugged.
When you run such code (that is executing run as shown in the video), the exception #BP is triggered after the int3 is executed (because #BP is trap type of exception) so RIP is pointing after the int3 instruction. At that moment the debugger knows that #BP happened and then the debugger usually looks at RIP-1 and finds there int3 (hexa 0CCh) and subtracts 1 from RIP so RIP is adjusted to point to the beginning of the int3 instruction. Debugger also looks into its internal data whether the int3 wasn't written there by the debugger itself (if not it leaves the int3 there which is the case in the video and if yes it restores the original byte there but this is not the case in the video).
When you execute debug exception (#DB) over int3 instruction (#BP) by setting rflags.TF=1 and then the code is run, #DB is generated because it has higher priority than #BP. It is also possible to avoid generating #DB for 1 instruction by setting rflags.RF (resume flag) and the processor clears the RF after the one instruction execution is successfully completed (except for IRET that sets the RF, except for JMP, CALL, INTn through a task gate).
The degugger could be improved to pass this situation. Something like this:
[0] lookup whether the int3 was written there by the debugger itself (e.g. because using a software breakpoint there)
[1] if yes then point RIP at the beginning of the int3 instruction (subtract 1 from RIP) and restore there the original byte (this is not the case in video as there the int3 was incompiled in the code)
[2] if not (that means the int3 was incompiled in the code) then do not decrease RIP and let the RIP to point after the int3 instruction.

That is a bug in X64dbg. It is very silly to expect the user to manually skip past INT3. Placing NOP there means you can't break again later if the INT3 is in a loop. The debugger should handle this stuff seamlessly without bothering the user.

Having the JIT window not show the INT3 upon startup,, and expecting the user to press buttons to show it, is also a bug.

Ollydbg always showed the faulting address immediately. And Olly would not get stuck on INT3.

what about INT 4 ?
there you can (for me at least ) continue with F7/F8. It jump briefly into another section, but then continues...
Or what I use often is, i place the EIP to the next instruction (CTRL+*), then F8 to continue.
NOPing the INT instrcution and placing a BP to next instrcution is a good idea, though.[/b]

INT 4 in 64 bit mode

AMD
24593.pdf
Table 2-3. Invalid Instructions in 64-Bit Mode
INTO, opcode (hex) CE, Interrupt to Overflow Vector

Intel
325383.pdf
INT n/INTO/INT3/INT1—Call to Interrupt Procedure
Opcode CE, Instruction INTO, 64-Bit Mode Invalid