AI for Engineers: How to Use LLMs for Coding, Simulation, Design & Research

Large Language Models (LLMs) are changing the way engineers interact with software, technical information, simulation environments, programming languages, and engineering documentation. While LLMs are often associated with chatbots and text generation, their engineering significance is much broader.

An LLM can act as a natural-language interface to programming environments, explain mathematical models, generate preliminary code, assist with debugging, summarise technical documentation, create test cases, interpret simulation results, and coordinate multiple steps in an engineering workflow.

Modern engineering platforms are already incorporating generative AI directly into tools used for modelling, simulation, embedded systems, and software development. For example, MATLAB and Simulink now provide generative and agentic AI capabilities intended to assist engineers with code, model creation, analysis, simulation, and documentation.

The important distinction, however, is that an LLM should not be treated as an autonomous replacement for engineering analysis. Engineering problems are constrained by physical laws, numerical stability, safety requirements, component limitations, tolerances, standards, and verification procedures.

An LLM can generate a mathematically plausible answer that is physically incorrect or produce code that executes successfully but implements the wrong engineering model. Consequently, the most useful architecture is generally engineer + LLM + engineering software + verification, rather than engineer replaced by LLM.

What Is an LLM?

A Large Language Model is a neural network trained to model relationships within sequences of tokens. Tokens may represent complete words, parts of words, punctuation, mathematical symbols, programming syntax, or other pieces of information. During inference, the model estimates probable subsequent tokens conditioned on the preceding context.

A simplified representation of next-token prediction can be written as

$$P(x_t|x_1,x_2,\ldots,x_{t-1})$$

where $x_t$ represents the next token and the preceding tokens form the model context.

Modern LLMs are generally based on the Transformer architecture. The Transformer introduced a mechanism called self-attention that allows the model to determine relationships between different tokens within a sequence. For engineering applications, this is particularly useful because technical problems frequently combine natural language, equations, programming code, variable names, specifications, and structured procedures.

The attention mechanism can be expressed in simplified form as

$$Attention(Q,K,V) = softmax\left(\frac{QK^T}{\sqrt{d_k}}\right)V$$

where $Q$, $K$, and $V$ represent query, key, and value matrices, and $d_k$ is the dimensionality of the key vectors.

This mathematical mechanism does not mean that an LLM inherently understands Maxwell’s equations, thermodynamics, circuit theory, finite-element mechanics, or control theory in the same way an engineer does. Instead, the model has learned statistical representations from its training and interaction context. Engineering reliability therefore depends heavily on how the model is connected to authoritative information, computational tools, simulation environments, and verification procedures.

Why LLMs Are Relevant to Engineering?

Engineering work contains an unusual combination of structured and unstructured information. An engineer may spend one part of a project deriving equations, another part writing MATLAB or Python code, another part searching documentation, another part configuring a simulation, and another part writing a report.

Traditionally, these activities are separated among different software tools. An LLM provides a natural-language layer that can connect them.

For example, an engineer could describe a requirement such as:

Design a DC-DC converter that converts a variable 24–36 V input into a regulated 48 V output at 500 W.

The LLM could help translate that requirement into engineering tasks: determine the operating range, calculate the approximate duty ratio, select a topology, estimate inductor and capacitor values, generate an initial simulation model, identify expected current stresses, and propose test cases.

However, each engineering calculation still needs to be independently checked.

This distinction is fundamental. LLMs are excellent at translating engineering intent into computational actions, but the resulting engineering solution must be validated against physics and requirements.

The LLM-Based Engineering Workflow

A practical LLM engineering system can be represented as a layered architecture.

This architecture is significantly more reliable than asking an LLM to produce a complete engineering solution from memory.

A robust system should provide the model with relevant specifications, equations, documentation, simulation results, and constraints. The model can then generate an intermediate solution that is tested using deterministic engineering software.

LLMs for Engineering Programming

One of the most immediately useful applications of LLMs is engineering programming. Engineers regularly use Python, MATLAB, C, C++, embedded C, JavaScript, Verilog, VHDL, and specialized scripting languages.

An LLM can generate an initial implementation from a natural-language requirement.

For example, an engineer might ask for a MATLAB implementation of a numerical method:

$$x_{k+1}=x_k-\frac{f(x_k)}{f'(x_k)}$$

The model can produce a Newton-Raphson implementation, explain the algorithm, add stopping criteria, and generate test cases.

However, numerical engineering code introduces issues that ordinary programming examples may not reveal. An implementation can fail because of division by a nearly zero derivative, poor initial conditions, floating-point limitations, convergence problems, or inappropriate termination criteria.

Therefore, generated engineering code should be evaluated using:

• unit testing,
• boundary-condition testing,
• numerical convergence analysis,
• dimensional consistency,
• comparison with analytical solutions,
• independent implementations,
• and simulation results.

Research into LLMs for software engineering similarly identifies applications including coding, requirements, design, repair, refactoring, documentation, and analytics while emphasizing the need for techniques that detect incorrect generated solutions.

LLMs and MATLAB

MATLAB is particularly interesting because engineering workflows frequently combine equations, numerical algorithms, visualization, signal processing, optimization, control systems, and simulation.

An LLM can help engineers transform a mathematical description into MATLAB code.

Consider a first-order system:

$$\tau\frac{dy(t)}{dt}+y(t)=Ku(t)$$

An engineer can ask an LLM to generate a MATLAB model, calculate the transfer function,

$$G(s)=\frac{K}{\tau s+1}$$

and produce step-response plots.

The LLM can also explain why the response changes when $K$ or $\tau$ is modified.

Modern MATLAB and Simulink capabilities increasingly incorporate generative AI into engineering workflows. MathWorks describes AI-assisted engineering activities including code generation, system explanation, test generation, documentation, model creation, analysis, and simulation.

The important engineering principle remains the same: the LLM generates or assists with the computational artifact, while MATLAB performs deterministic numerical calculations.

LLMs for Simulink and Model-Based Design

Simulink provides another important use case because many engineering problems are represented as block diagrams rather than conventional source code.

An LLM can potentially translate a verbal system description into a sequence of modeling steps.

For example

 

For a motor-control system, for example, the LLM could help identify blocks associated with a reference signal, controller, PWM generator, inverter, motor model, sensors, and feedback loop.

The model could then be simulated, and the resulting speed, torque, current, voltage, and error signals analyzed.

The distinction between generating a model and validating a model is extremely important. A visually correct Simulink diagram does not guarantee that the equations, units, initial conditions, solver configuration, or parameter values are correct.

LLMs for Circuit Design

Electrical engineers can use LLMs for preliminary circuit analysis and design assistance.

For a resistive voltage divider,

$$V_{out}=V_{in}\frac{R_2}{R_1+R_2}$$

an LLM can rearrange the equation to determine a resistor value for a specified output.

For an RC low-pass filter,

$$f_c=\frac{1}{2\pi RC}$$

the model can calculate an initial combination of $R$ and $C$.

For a more complicated power-electronics system, however, the problem becomes substantially more difficult.

Consider a boost converter:

$$V_o=\frac{V_{in}}{1-D}$$

under ideal continuous-conduction assumptions.

An LLM may calculate the required duty cycle:

$$D=1-\frac{V_{in}}{V_o}$$

but that is only the beginning of the engineering problem.

A practical design must also consider switching frequency, inductor ripple current, capacitor ripple voltage, semiconductor losses, ESR, thermal constraints, control-loop stability, electromagnetic interference, transient response, operating modes, and component ratings.

Therefore, LLMs are most useful for design-space exploration and engineering assistance, while detailed verification should be performed using circuit simulation, analytical calculations, datasheets, and laboratory measurements.

LLMs for Engineering Simulation

Simulation is one of the most promising applications of LLM-based engineering systems.

An LLM can potentially generate:

• simulation scripts,
• parameter sweeps,
• initial model configurations,
• test scenarios,
• data-processing scripts,
• plots,
• sensitivity studies,
• and simulation documentation.

Suppose an engineer is investigating the effect of switching frequency on converter efficiency.

Instead of manually changing the parameter repeatedly, an LLM-assisted workflow could generate a simulation sweep:

$$f_s \in \{10\,kHz,20\,kHz,50\,kHz,100\,kHz\}$$

The simulation engine produces efficiency values

$$\eta=\frac{P_{out}}{P_{in}}\times100$$

and the resulting data can be plotted.

The LLM can then help interpret trends, but it should not invent a physical explanation unsupported by the simulation data.

LLMs and Engineering Optimization

Optimization provides another important application.

A general engineering optimization problem can be represented as

$$\min_x f(x)$$

subject to

$$g_i(x)\leq0$$

and

$$h_j(x)=0.$$

Here $x$ represents the design variables.

For an electric motor, $x$ might contain dimensions, winding parameters, current density, material properties, and operating variables.

For a power converter, $x$ could include switching frequency, inductance, capacitance, duty ratio, semiconductor selection, and thermal parameters.

An LLM can help formulate the optimization problem, generate code, explain optimization algorithms, and interpret results. However, the optimization algorithm itself should evaluate the actual engineering objective using validated models.

This leads to a powerful architecture:

The LLM acts as an interface and reasoning assistant rather than the numerical optimiser itself.

LLMs for Control Engineering

Control engineering presents both significant opportunities and significant risks.

An LLM can explain PID control, generate controller code, derive transfer functions, create MATLAB scripts, and suggest simulation experiments.

For a PID controller,

$$u(t)=K_pe(t)+K_i\int e(t)dt+K_d\frac{de(t)}{dt}$$

an LLM can explain the effects of proportional, integral, and derivative gains.

It can also generate an initial MATLAB script for tuning experiments.

However, selecting controller gains for a safety-critical physical system requires considerably more than language-model reasoning. Stability margins, actuator saturation, sensor noise, delays, nonlinearities, disturbances, sampling frequency, and plant uncertainty all need to be evaluated.

Consequently, an LLM-generated controller should be regarded as an initial engineering artifact requiring analysis and testing.

LLMs for Embedded Systems

Embedded engineering combines software and hardware constraints, making it another important area for LLM applications.

An engineer may ask an LLM to generate code for:

• GPIO control,
• UART communication,
• SPI,
• I²C,
• ADC acquisition,
• PWM generation,
• interrupt routines,
• sensor interfacing,
• timers,
• state machines,
• and communication protocols.

For example, an LLM can generate a conceptual embedded workflow:

 

The difficulty arises because embedded systems are constrained by real-time deadlines, memory, processor architecture, peripheral configuration, interrupt latency, hardware registers, compiler behaviour, and electrical interfaces.

A generated C program may compile correctly but still fail on the actual microcontroller because a register configuration, timing assumption, clock frequency, or peripheral mode is incorrect.

The engineering workflow should therefore include compilation, static analysis, hardware-in-the-loop testing, oscilloscope measurements, and system-level verification.

LLMs for Engineering Research

LLMs can also change the research workflow.

Engineering researchers spend significant amounts of time reading papers, comparing methodologies, understanding mathematical formulations, preparing datasets, writing code, debugging implementations, and documenting experiments.

An LLM can help transform a research problem into a structured workflow:

 

For example, in machine-learning-based electrical engineering research, an LLM could help create Python preprocessing code, explain feature engineering, generate baseline models, produce visualization scripts, and help organize experimental results.

But researchers should verify citations, equations, datasets, experimental claims, and references independently. An LLM can produce authoritative-looking statements that are not supported by the underlying literature.

Retrieval-Augmented Generation for Engineering

One of the most useful techniques for engineering LLM systems is Retrieval-Augmented Generation (RAG).

Instead of relying exclusively on information encoded in model parameters, a RAG system retrieves relevant information from an external knowledge base before generating an answer.

A simplified architecture is:

This approach can be especially useful when engineers need answers based on specific component datasheets, company design standards, laboratory manuals, equipment documentation, or project specifications.

For example, instead of asking an LLM:

What is the maximum operating temperature of this MOSFET?

the system can retrieve the manufacturer’s datasheet and answer using the relevant specification.

This significantly changes the engineering problem from “Does the model remember the answer?” to “Can the system retrieve the correct authoritative information and use it correctly?”

LLMs and Digital Twins

The combination of LLMs and digital twins is another emerging engineering direction.

A digital twin can represent a physical system through computational models, measurements, simulations, and operational data.

An LLM can provide a natural-language interface to that digital representation.

For example, an engineer might ask:

Why did the predicted motor temperature increase during the last operating cycle?

A properly integrated system could retrieve sensor data, inspect model outputs, identify relevant operating conditions, execute analysis code, and present the results.

Conceptually:

Physical System
      │
      ▼
Sensors / IoT
      │
      ▼
Data Platform
      │
      ▼
Digital Twin
      │
      ├──────────────► Simulation
      │
      ├──────────────► Analytics
      │
      ▼
     LLM
      │
      ▼
Natural-Language Engineering Interface

The LLM therefore becomes an interface between human engineers and complex computational systems.

LLMs for Engineering Documentation

Documentation is another area where LLMs can provide substantial productivity benefits.

Engineering projects generate large quantities of documentation, including requirements, design descriptions, test procedures, maintenance instructions, software documentation, simulation reports, and verification records.

An LLM can convert technical notes into structured documentation, explain code, summarize test results, generate preliminary requirements, and identify missing information.

However, engineering documentation should preserve traceability.

A useful requirement-to-verification chain is:

$$Requirement \rightarrow Design \rightarrow Implementation \rightarrow Test \rightarrow Evidence$$

Every important engineering requirement should ideally be traceable to a design element and an associated verification method.

Recent engineering discussions around AI-enabled digital engineering similarly emphasize that AI-generated engineering outputs need to remain traceable, testable, reviewable, and governed.

LLMs and Engineering Troubleshooting

Troubleshooting is particularly well suited to conversational interfaces.

Consider a system producing an unexpected waveform. An engineer can provide:

• measured voltage,
• current waveform,
• switching frequency,
• load,
• temperature,
• simulation parameters,
• component specifications,
• and error messages.

The LLM can organize possible causes into a diagnostic tree.

Unexpected Output
       │
       ▼
Check Measurement
       │
       ├── Incorrect → Sensor / Probe / Instrument
       │
       └── Correct
             │
             ▼
       Check Input Conditions
             │
             ▼
       Check Component Parameters
             │
             ▼
       Check Control Signals
             │
             ▼
       Check Simulation / Model
             │
             ▼
       Compare With Expected Physics

This can dramatically reduce the time required to search documentation and organize possible causes.

Nevertheless, troubleshooting suggestions should be hypotheses until supported by measurement or analysis.

Why LLM Hallucinations Are Particularly Dangerous in Engineering

Hallucination is one of the most important limitations of LLMs in technical applications.

An LLM can produce a statement that is linguistically convincing but factually incorrect.

In engineering, this can result in:

• incorrect equations,
• incorrect units,
• nonexistent standards,
• incorrect component specifications,
• invalid assumptions,
• fabricated citations,
• incorrect code,
• unstable controllers,
• incorrect circuit parameters,
• and unsafe operating recommendations.

The problem is not simply that the model occasionally makes mistakes. The deeper issue is that the model may communicate an incorrect result with high confidence.

For this reason, engineering AI systems should use deterministic verification wherever possible.

A useful principle is:

Use the LLM for generation and interpretation; use engineering tools for calculation and verification.

Verification Architecture for Engineering LLMs

A robust architecture should introduce multiple verification layers.

                 LLM OUTPUT
                     │
          ┌──────────┴──────────┐
          ▼                     ▼
    Logical Review        Source Verification
          │                     │
          └──────────┬──────────┘
                     ▼
             Mathematical Check
                     │
                     ▼
             Numerical Simulation
                     │
                     ▼
             Physical Constraints
                     │
                     ▼
               Safety Review
                     │
                     ▼
             ENGINEER APPROVAL

For safety-sensitive applications, this should be expanded to include formal requirements, independent verification, testing, and appropriate organizational controls.

NIST’s AI Risk Management Framework emphasizes managing AI risks throughout design, development, deployment, use, and evaluation. Its Generative AI Profile specifically addresses risks associated with generative AI and provides actions for organizations to manage those risks.

A Quantitative Way to Think About LLM Engineering Reliability

Engineering teams can also evaluate an LLM system quantitatively.

Suppose a system performs $N$ engineering tasks and produces $N_c$ outputs that pass an independent verification procedure.

A basic verified success rate can be defined as

$$R_v=\frac{N_c}{N}.$$

For example, if 950 out of 1,000 generated code tasks pass the predefined verification process,

$$R_v=0.95.$$

However, this metric alone is insufficient.

An engineering evaluation should also consider:

$$Accuracy, \quad Robustness, \quad Latency, \quad Cost, \quad Traceability, \quad Safety, \quad Reproducibility.$$

A system that produces correct answers but cannot explain their provenance may be unsuitable for regulated engineering environments.

Where LLMs Should Not Be Trusted Without Verification

An LLM should not be treated as the final authority for calculations involving safety-critical structures, electrical protection, high-voltage systems, thermal limits, aircraft systems, medical devices, structural integrity, or other applications where an incorrect decision can cause significant physical harm.

This does not mean that LLMs cannot be used in these areas. Rather, their role should be constrained.

For example, an LLM can help an engineer understand a protection-system specification, generate a preliminary calculation, or organize a test plan. The final engineering decision should be based on applicable standards, validated calculations, qualified engineering judgment, testing, and organizational review.

NIST describes trustworthy AI characteristics including validity and reliability, safety, security and resilience, accountability and transparency, explainability and interpretability, privacy, and fairness.

From LLMs to Engineering Agents

The next step beyond conventional LLM assistants is the engineering agent.

A conventional LLM responds to a prompt.

An engineering agent can potentially:

1. Understand the engineering requirement.
2. Retrieve relevant documentation.
3. Generate code.
4. Execute the code.
5. Inspect the output.
6. Modify parameters.
7. Run another simulation.
8. Compare the results with requirements.
9. Generate a report.

The conceptual architecture looks like this:

             ENGINEERING OBJECTIVE
                     │
                     ▼
               LLM / AGENT
                     │
          ┌──────────┼──────────┐
          ▼          ▼          ▼
       Search      Coding    Simulation
          │          │          │
          └──────────┼──────────┘
                     ▼
                Results
                     │
                     ▼
              Evaluation Agent
                     │
             ┌───────┴───────┐
             │               │
          PASS              FAIL
             │               │
             ▼               ▼
          Report        Modify Model
                             │
                             └──────► Simulation

This creates a closed engineering workflow in which AI can iteratively interact with software tools.

Current engineering software is already moving toward this model. MathWorks describes agentic workflows in which AI agents can interact with MATLAB and Simulink for activities such as running code, creating models, inspecting outputs, simulating behavior, and supporting engineering review.

LLMs Across Different Engineering Disciplines

The applications of LLMs differ according to engineering discipline.

In electrical engineering, LLMs can assist with circuit analysis, embedded programming, signal processing, control systems, power electronics, PCB documentation, and simulation.

In electronics engineering, they can assist with microcontroller code, communication protocols, sensor interfacing, FPGA development, Verilog/VHDL generation, and debugging.

In mechanical engineering, LLMs can support CAD workflows, manufacturing documentation, computational analysis scripts, material-property research, and optimization.

In civil engineering, applications include document analysis, structural analysis assistance, construction planning, project documentation, and infrastructure monitoring.

In chemical and process engineering, emerging research is examining LLM applications in process design, modeling and simulation, forecasting, optimization, process control, and fault diagnosis. Recent research also highlights that applications requiring real-time execution, strict constraint satisfaction, or formal safety guarantees remain challenging.

In computer engineering, LLMs are particularly relevant to software development, embedded systems, cybersecurity, hardware-description languages, verification, and system architecture.

LLM + Human Engineer: The Most Practical Model

The strongest engineering workflow is not simply “AI does engineering.”

A more realistic architecture is:

$$Human\ Engineer + LLM + Engineering\ Software + Authoritative\ Data + Verification$$

Each component has a different responsibility.

The engineer defines the problem and constraints. The LLM translates requirements into useful actions and assists with reasoning and communication. Engineering software performs deterministic calculations and simulations. Authoritative data provides specifications and domain knowledge. Verification determines whether the resulting design actually satisfies the requirements.

This division of responsibilities is critical because LLMs are probabilistic systems, while many engineering requirements are deterministic.

How Engineers Can Start Using LLMs Today

An engineer does not need to build a sophisticated AI agent to benefit from LLM technology.

A practical workflow begins with relatively low-risk tasks.

First, use an LLM to explain documentation, equations, algorithms, or programming concepts.

Second, use it to generate preliminary MATLAB, Python, C, or C++ code.

Third, execute the generated code in the appropriate engineering environment.

Fourth, compare the output with an analytical calculation or known reference.

Fifth, progressively introduce more complex tasks such as parameter sweeps, simulation automation, report generation, and documentation.

This gradual approach allows engineers to gain productivity without immediately handing critical engineering decisions to an unverified AI system.

The Future of LLMs in Engineering

The future of engineering AI is likely to involve increasingly integrated systems rather than standalone chat interfaces.

An engineer may eventually describe a design objective in natural language and have an AI system retrieve specifications, generate models, execute simulations, perform optimization, inspect results, generate documentation, and prepare verification evidence.

The resulting engineering environment could look like:

$$Natural\ Language \rightarrow Requirements \rightarrow Model \rightarrow Simulation \rightarrow Optimization \rightarrow Verification \rightarrow Documentation$$

However, the most important technology may not be the LLM itself. The critical infrastructure will include reliable retrieval systems, deterministic engineering tools, simulation environments, test frameworks, traceability mechanisms, access controls, and human review.

This is why the future of LLM engineering is likely to be less about asking a chatbot questions and more about integrating language models into complete engineering toolchains.

Conclusion

Large Language Models are becoming useful engineering assistants because they can connect natural-language requirements with programming, simulation, documentation, technical knowledge, and computational tools. Their value is particularly evident in activities such as MATLAB programming, Simulink modeling, embedded development, circuit analysis, engineering research, optimization, documentation, and troubleshooting.

However, engineering imposes requirements that ordinary conversational AI does not. A physically incorrect result can be far more serious than a poorly written paragraph. Engineers therefore need workflows in which LLM-generated outputs are checked using mathematics, simulation, measurements, authoritative documentation, testing, and engineering judgment.

The most promising direction is consequently not LLM versus engineer, but LLM + engineer + engineering software + verified data.

As engineering platforms increasingly integrate generative and agentic AI, engineers who understand both the capabilities and limitations of these systems will be better positioned to use them effectively. The future engineering workflow may begin with a natural-language requirement, but it should end with a design that has been calculated, simulated, tested, documented, and verified.

Key Takeaways

LLMs can assist engineers with coding, simulation, documentation, research, optimization, troubleshooting, and technical knowledge retrieval. They are particularly powerful when connected to deterministic engineering software such as MATLAB, Simulink, Python-based scientific computing environments, CAD systems, and simulation platforms.

The critical limitation is that language-model output is not automatically an engineering result. Every important result must be checked against physical laws, numerical calculations, specifications, constraints, and experimental evidence.

The strongest engineering AI architecture therefore combines human engineering expertise, large language models, authoritative technical information, computational tools, simulation, and independent verification.

For engineers, the important question is no longer simply whether LLMs can generate text or code. The more important question is how these models can be integrated into engineering workflows while preserving accuracy, traceability, safety, reproducibility, and human control.