Part of what signaru described but in Lazarus/FPC (and Delphi) it actually generalizes more - it isn't just the GUI that you can edit visually in the IDE and you aren't just editing some sort of visual stand-in/proxy: instead what the IDE edits is "live" object instances, there is support for properties at the language level as well as enough RTTI and metaclass functionality to be able to reflect an object's making and state at runtime, which allows for things like object serialization and editing said live object instances via property editors. In Lazarus (and Delphi) programs are made up of "components" (which are just subclasses of the TComponent class) and these components lie inside "packages" which are basically libraries - the same libraries your program will use - that are linked against the IDE. The libraries register the classes with the framework and the IDE (which is written against its own framework) queries the registered classes and can use them in the visual designers: when you place a component on a form you are creating an instance of a registered component class, the properties of that instance show up in the object inspector allowing you to edit them in place. When you save the form, the objects in it are serialized to the form file.
This is how the GUI editing works, but there is more to that since components do not have to be visual elements. For example check this screenshot[0], this shows some components from a package i have written that i use across various tools (mainly 3D related). The edited form (which btw is a component itself) has a visual component that represents a 3D viewport (the big black box) and four non-visual components, a component that represents a fragment/vertex shader pair for OpenGL, a component that provides undo/redo management, a component that represents a manager for all viewports and a component that can be used to render multiple viewports at the same time. The first component (the shader pair one) has its properties shown in the object inspector at the left with a "strings" editor opened for editing the FragmentCode property (which is a collection of strings meant to represent lines in an editor) and shows some GLSL code. The undo manager has its own properties and two of them are "UndoAction" and "RedoAction", meant to be assigned to "TAction" instances that will be automatically updated whenever undo events are handled. TAction is a non-visual component provided by Lazarus itself that can be used to represent GUI actions that can be invoked via various places (e.g. menu items, toolbar buttons or programmatically) so that instead of writing code against menu items, buttons, etc directly you write the code against the action and then associate the action with the menus, buttons, etc you want.
Another thing to note is that so far i mentioned GUIs but Lazarus (and Delphi) is not limited to that. As i wrote above a form (window) itself is also a component but there are also non-visual "toplevel" components too: data modules. These can contain only non-visual components (and you can even use them in non-GUI applications, e.g. command line applications or web applications). Some are used to "RAD" only meaning GUI editors and might find that weird, but if you take all of the above in consideration, it becomes obvious that since you can edit non-visual objects in a form via the IDE you may also want to be able to edit only non-visual objects in a non-visual container (which also allows making programs without a GUI while still being able to edit objects visually via the IDE).
In fact one may use the aforementioned actions but placing them inside a data module instead of a form, thus separating the logic of the program from its GUI while still being able to take advantage of the IDE's visual editing functionality.
In a way it is similar to how some game engines like, e.g. Unreal Engine, work (though UE needs a preprocessor to generate the class information while Lazarus/Delphi use language features) and is probably among the closest you can get to a Smalltalk-like environment without being able to serialize the entire environment to disk and instead working on a traditional "edit, build, run" cycle with clearly separated "editing" and "running" states.
This is how the GUI editing works, but there is more to that since components do not have to be visual elements. For example check this screenshot[0], this shows some components from a package i have written that i use across various tools (mainly 3D related). The edited form (which btw is a component itself) has a visual component that represents a 3D viewport (the big black box) and four non-visual components, a component that represents a fragment/vertex shader pair for OpenGL, a component that provides undo/redo management, a component that represents a manager for all viewports and a component that can be used to render multiple viewports at the same time. The first component (the shader pair one) has its properties shown in the object inspector at the left with a "strings" editor opened for editing the FragmentCode property (which is a collection of strings meant to represent lines in an editor) and shows some GLSL code. The undo manager has its own properties and two of them are "UndoAction" and "RedoAction", meant to be assigned to "TAction" instances that will be automatically updated whenever undo events are handled. TAction is a non-visual component provided by Lazarus itself that can be used to represent GUI actions that can be invoked via various places (e.g. menu items, toolbar buttons or programmatically) so that instead of writing code against menu items, buttons, etc directly you write the code against the action and then associate the action with the menus, buttons, etc you want.
Another thing to note is that so far i mentioned GUIs but Lazarus (and Delphi) is not limited to that. As i wrote above a form (window) itself is also a component but there are also non-visual "toplevel" components too: data modules. These can contain only non-visual components (and you can even use them in non-GUI applications, e.g. command line applications or web applications). Some are used to "RAD" only meaning GUI editors and might find that weird, but if you take all of the above in consideration, it becomes obvious that since you can edit non-visual objects in a form via the IDE you may also want to be able to edit only non-visual objects in a non-visual container (which also allows making programs without a GUI while still being able to edit objects visually via the IDE).
In fact one may use the aforementioned actions but placing them inside a data module instead of a form, thus separating the logic of the program from its GUI while still being able to take advantage of the IDE's visual editing functionality.
In a way it is similar to how some game engines like, e.g. Unreal Engine, work (though UE needs a preprocessor to generate the class information while Lazarus/Delphi use language features) and is probably among the closest you can get to a Smalltalk-like environment without being able to serialize the entire environment to disk and instead working on a traditional "edit, build, run" cycle with clearly separated "editing" and "running" states.
[0] https://i.imgur.com/Yw1tTcD.png