What you are describing is coding. In non-software engineering, this is on a “level” of the V-model close to “implementation” (detailed design), similar to producing a CAD model, which are the instructions that tell a CNC machine or a machine operator (lathe, mill, sheet press, sheet-bending machine, etc.) what to do–i.e., the implementation.
And even then, the person in charge of producing the CAD model is (hopefully, but you’d be surprised) not a mindless, ignorant draftsman drawing lines in 2D or 3D without care, but someone who has enough knowledge of engineering to understand the trade-offs behind mechanical design decisions, such as stress concentration, engineering tolerances, or anything else that might impact how a line is drawn and how it connects to other lines.
The drawing is to the operator what the codebase is to the computer. That doesn’t mean that the process leading to the “implementation instructions” does not resemble engineering, regardless of the artifact being engineered.
I mean, of course you can go ahead and be a tinkerer, i.e. someone who goes to the junkyard, pulls things that seem they might fit together, and then kinda puts them together into something that might work or might not, depending on the system’s context and the properties of its components.
This is equivalent to copy-pasting code from Stack Overflow or from an LLM chat without actually understanding what it does, what it does not, what it does badly and when, and how it fails, and how its failure will impact the overall “system”. Vibe-coding and coding by copy-pasting is (usually, for most enthusiasts) the low-knowledge and low-understanding slapping-together-things-until-they-maybe-somehow-work-together equivalent of tinkering.
Engineering though requires understanding the system, its architecture, its components, how they connect, how they should work vs. how they work, why they work this way and not that way, under which conditions the components and subsystems/assemblies will work in isolation and together as you specified them, so that the system fulfills the requirements posed on it, when the components, subsystems/assemblies and the entire system is expected to fail and why (see FMEA). And the story goes all the way up both sides of the V, so that you understand what it is you’re building to begin with, and how you will know you’ve succeeded, and to what extent, and with which “gremlins in the system”.
When you “code”, you might not be engineering the software, except if you’ve put forethought on the design that drives the code, the architecture that drives how everything “talks” to other things within the codebase, the requirements that impact the architecture you choose (from how you lay out your Elixir modules to whether you have microservices or a monolith or anything else), etc.
When you engineer the software, you have to build knowledge early enough, so that you can make better decisions. You don’t need to wait until the whole left branch of the V-model is “perfect”. You can experiment (e.g. in IEx) and build knowledge. But that’s no different to engineers 3D printing mock-ups, for example to test ergonomics, or running FEM analyses to figure out whether a requirement is realistic to begin with (“Can I make it as light as they think we should?” Can we bend that sheet how the industrial designer hoped we can without compromising drop-resistance?” and so on).
Every kind of engineering has its own modalities, such as degree of mutability (and the cost of changes) of the artifact depending on how far along you are along the process from an idea to a prototype or a ready-to-launch product (or refinery, or defibrilator, or building, or anything else).
Software too; when you don’t just write a script but you engineer a software system (or a subsystem, like an Elixir module), you engineer it like any artifact beholden to any other engineering discipline(s).
Coding, i.e. “writing a set of instructions that tell the computer what do to”, a “script” as you call it, is merely the implementation.
Edit: @adamu just think about the word “coding”: you are literally encoding a design into instructions. So, you cannot have instructions without this encoding, and therefore you can’t have implementation without some degree of design. And so, you are in the engineering process already, but perhaps not all the way to the top of the left branch of the V 
but people often get carried away, especially the closer you get to getting an order, or being able to issue an invoice. People in different business functions are clustered around different character archetypes. I could never be in direct sales and “knocking on doors” or “pounding pavement”, because I hate its stochastic nature, and the need for hyperbole that goes with it all too often… But others thrive on this as a source of excitement, and thus tend to over-overpromise, and then indirectly increase expectations on everyone else who’s tasked with the product, because management after all (generally) tends to take the idiotic “don’t bring me problems, bring me solutions” stance above the “I don’t know, how can we figure it out?” stance.
):