A Blueprint for the Modern Self-Sufficient Engineering Company

1. The bottleneck is moving

An engineer knows exactly what needs improving: a thermal report takes half a day to assemble; a stress-analysis workflow requires the same manual edits for every variant; a production problem needs data from three systems that do not talk to each other. The idea is not missing. The implementation capacity is.

Historically, that meant a software request, a budget discussion, a consultant, or a place in someone else's backlog. Some useful tools never got built. LLM-assisted coding changes the economics of that last mile: an engineer can describe the workflow, provide representative inputs and expected results, and iterate on a working implementation.

An improvement that sat on a roadmap for years can sometimes become a usable prototype in days. That is a statement about removing waiting and implementation friction, not a claim that years of numerical-method development or product qualification have disappeared. A file converter and a certified structural-analysis system are not the same kind of deliverable.

This connects directly to my earlier argument about the flaw in calling engineering tools “outdated”. A mature in-house code may encode decades of validated practice. The opportunity is often to make it easier to use, automate, test, and maintain, not to replace it because its interface looks old.

The company already understands the problem. What is changing is how directly that understanding can become working software.

2. Mechanical and aerospace engineers become tool builders

A mechanical engineer does not need to become a full-time application developer to start building a fixture calculator, a test-data processor, or a parameterized analysis workflow. An aerospace engineer can direct the development of a load-case generator or a simulation comparison tool using engineering requirements rather than starting with a blank code editor.

The productive division of work is clear: the engineer defines the physics, assumptions, operating envelope, and acceptance criteria; the LLM helps implement interfaces, scripts, tests, and documentation; software specialists review the architecture, security, and maintainability where the consequences justify it.

That reduces dependence on coding teams for every small change. It does not make coding knowledge irrelevant. Engineers still need enough software literacy to inspect a change, understand dependencies, recognize a failed test, and know when to seek review. Complex solutions become more approachable when assembled from tested components, not when complexity is hidden behind a prompt.

The LLM-orchestrated OpenFOAM study, Turbulence Realm analysis tools, and Earth Intelligence project illustrate different parts of this shorter implementation loop. They are examples of what can be built, not evidence that every generated tool is ready for production.

3. Open-source LLMs at frontier performance levels

The important shift is that leading open-source and open-weight LLMs can compete at frontier performance levels on selected coding, reasoning, and tool-use benchmarks. Openness no longer automatically means settling for a low-capability assistant. For engineering teams, that creates the possibility of combining advanced implementation support with control over deployment, data, and model choice.

Kimi and GLM are examples of this broader shift, not the foundation of the strategy. Moonshot AI's Kimi K3 releases full weights for a natively multimodal agentic model with a 1-million-token context, aimed at long-horizon coding, knowledge work, and reasoning, under the Kimi K3 License: permissive terms that add conditions mainly for very large model-as-a-service providers and high-reach commercial products. Z.AI's GLM-5 series takes a similar direction: GLM-5.3 targets complex software engineering and long-horizon agent tasks with a 1-million-token context under the comparably permissive GLM-5.3 License, while GLM-5.3-Flash delivers a smaller, natively multimodal variant under the plain MIT license. Their published evaluations illustrate the competitiveness of open-weight models with leading proprietary systems. Performance varies by model, task, and evaluation setup; these developer-reported benchmarks are not proof of equivalent reliability across every engineering workflow. [1] [2]

Proprietary coding assistants can still be useful, but an independence strategy should not depend entirely on one hosted API. With suitable open models, a company can run approved inference inside a controlled environment, choose its deployment architecture, and replace the model as capabilities improve. Keep workflows, evaluation cases, and company knowledge portable rather than building them around one provider's product.

“Open source” needs care here. Many models commonly described that way are more precisely open-weight: accessible weights do not necessarily mean the complete training data and training pipeline are available. Check the license and available artifacts for the exact release, including additional conditions. The practical theme is control over capable models and the engineering tools built around them, not treating every release as equally open.

Self-hosting also has a real cost. Large mixture-of-experts models can require substantial aggregate memory, accelerators, and operational support; the number of parameters active per token is not the total memory requirement. A smaller approved model may suit routine scripting, while a larger model handles difficult development tasks. Evaluate them on the company's actual repositories and engineering cases, not just public coding benchmarks.

That evaluation deserves its own small internal tool: a versioned benchmark of representative work: a test-data parser with known outputs, a CFD case-setup task, a refactor of an existing utility, and deliberately broken inputs that must be detected rather than silently accepted. Run candidate models against it on every upgrade; record pass rate, cost, latency, and failure modes; and keep the suite permission-controlled like any other proprietary asset. An afternoon of internal evidence is worth more than any public leaderboard when deciding which model earns a place in the workflow.

4. Improve analysis without starting over

The fastest route to value is usually around an existing solver. LLMs can help create repeatable inputs, expose useful controls, connect datasets, and standardize outputs. They can also assist with source-code changes, but a new boundary condition or material model needs a much stronger review and verification process than a report generator. The same applies well beyond CFD and structural mechanics: vibration and modal analysis, fatigue and durability, acoustics, electromagnetics, and multibody dynamics each carry their own solvers, conventions, and validation evidence.

These foundations already exist. OpenFOAM function objects support runtime and batch post-processing; ParaView exposes Python scripting; CalculiX supports linear and nonlinear calculations, including static, dynamic, and thermal solutions; Code_Aster adds open-source structural, thermal, dynamics, vibration, and fatigue capabilities developed and qualified at EDF; and Elmer extends into multiphysics problems such as acoustics and electromagnetics. The LLM helps engineers connect and customize these capabilities rather than inventing numerical physics from scratch. [3] [4] [5] [12] [13]

There is an important distinction between a better workflow and a more accurate model of reality. An automated mesh sweep can improve consistency. A prettier contour plot cannot establish accuracy. That is also the lesson of the simulation-on-simulation trap: copying a simulation's assumptions into another model does not independently validate them.

The same ownership extends one level higher. Open frameworks such as NASA's OpenMDAO let a team couple its analyses into multidisciplinary design studies, linking aerodynamics, structures, thermal, and cost models, then running gradient-based or gradient-free optimization across large design spaces. An LLM can help write the component wrappers, interfaces, and problem setup; the couplings, derivatives, and physics remain the engineer's responsibility. [14]

5. OpenFOAM: complex physics, workflows you can own

OpenFOAM is not limited to simple demonstration flows. The OpenFOAM Foundation distributes a mature, free, open-source CFD platform, developed and maintained by CFD Direct, that covers fluid motion, heat transfer, thermodynamics, and chemistry. Its GPLv3 licensing allows companies to inspect and extend the source. Internal modifications do not have to be published merely because they are made; distributing GPL-covered software brings licensing obligations that need to be reviewed. [9]

Established capabilities for demanding industrial flows

The Foundation's chemical and process engineering overview documents capabilities that go well beyond single-phase external aerodynamics: [10]

• Turbulent flows: Reynolds-averaged models, stress closures, large-eddy simulation, and multiphase turbulence models.
• Multiphase systems: volume-of-fluid interface capturing for immiscible fluids and Euler–Euler modelling of dispersed phases, including interphase heat and mass transfer.
• Particle-laden flows: Lagrangian modelling of sparse and dense particle systems, with applications such as sprays, fluidised beds, separation, and filtration.
• Thermal and reacting flows: conjugate heat transfer across multiple fluid and solid regions, natural convection, and single- or multiphase turbulent reactions and combustion.
• Moving and rotating systems: rotating-geometry and mesh-motion capabilities for applications such as mixers and impellers, alongside engineering-geometry meshing and adaptive refinement.

These capabilities give an internal team a serious numerical foundation to build on. An LLM can help automate case preparation, parameter studies, post-processing, or reviewed extensions; it is not what makes the underlying solver capable of complex physics. Model selection, numerical resolution, and validation still determine whether a particular prediction is fit for purpose.

Open source does not mean unsupported. CFD Direct offers optional professional support for physical modelling, meshing, numerics, parallel execution, post-processing automation, and code customization. A company can retain ownership of its workflows while buying targeted expertise when needed. The Foundation also describes a Process Engineering Consortium through which industrial users help fund development, contribute test cases, and guide improvements. [11] [10]

A practical workflow a company can own

Consider a team repeatedly assessing pressure drop and cooling performance across a family of industrial components. The following is an illustrative workflow, not a reported deployment or a guaranteed schedule.

1. Start with a trusted case. An engineer supplies a baseline, units, geometry conventions, material properties, operating conditions, and test evidence. Pin the OpenFOAM distribution and version: dictionaries and solver interfaces are not interchangeable across every release.
2. Generate controlled variants. An LLM helps write scripts that populate approved templates, check inputs, generate meshes, and submit jobs. Geometry, meshing, and solver settings remain traceable to a specific revision.
3. Reject bad runs explicitly. Check mesh quality, solver exit status, mass and energy balance, residual trends, and stabilization of relevant engineering quantities. Low residuals alone do not demonstrate physical accuracy.
4. Automate the repetitive analysis. Use function objects and ParaView's pvbatch to extract consistent metrics, plots, and comparisons. Record failed and inconclusive runs rather than silently dropping them.
5. Compare against independent evidence. Benchmark against analytical cases where applicable and calibrated measurements in the relevant operating range. Keep validation cases separate from any calibration data.
6. Package and maintain the workflow. Provide a simple internal interface, versioned environments, regression tests, an owner, and an approval path for changes to the underlying physics.

Once reviewed, much of this pipeline should run as ordinary deterministic software. It does not need an LLM to improvise every production run. Use the model to help build the automation; do not introduce a model dependency where a tested script is sufficient.

If a new heat-transfer correlation or constitutive law is genuinely needed, the LLM can assist with implementation and tests. The derivation, applicability, numerical verification, and experimental validation remain engineering work. The productivity gain is real without claiming that an unreviewed solver modification is trustworthy.

6. From the analysis desk to the factory floor

The same approach extends beyond CFD and FEA. Engineers who understand production constraints can develop useful automation with controls, quality, maintenance, and IT support. Node-RED offers reusable event-driven flows, while ROS-Industrial provides interfaces and capabilities for manufacturing robotics, perception, calibration, and motion planning. [6] [7]

• Condition monitoring: connect approved vibration, current, pressure, and temperature data; build trend dashboards and maintenance alerts. Validate thresholds against operating regimes and labeled events before claiming predictive maintenance.
• Quality and inspection: build camera-calibration utilities, dimensional checks, defect-review interfaces, and links between inspection results and process history. Measure false accepts and false rejects on representative parts.
• Test-bench automation: coordinate approved instrument interfaces, capture calibration metadata, check units, and generate traceable reports instead of manually moving numbers between spreadsheets.
• Process and energy improvement: compare furnace recipes, compressed-air demand, coolant performance, or machine idle time. Use engineering constraints and controlled trials to test proposed changes rather than treating correlation as causation.
• Scheduling and traceability: create discrete-event simulations, bottleneck dashboards, batch genealogy, and work-order connectors through supported interfaces. Start with read-only access to production systems.
• Robotics support: develop offline path-generation tools, sensor integration, inspection routines, and simulated workcells using suitable ROS-Industrial components. Qualify the complete application on the actual hardware.

MQTT or OPC UA can provide integration paths where the equipment supports them. LLMs can help implement adapters and diagnostics, but engineers must specify tag meanings, timestamps, units, access controls, and behavior during connection failures. A plausible dashboard built on misinterpreted signals is worse than no dashboard.

My posts on small-board sensing and automation and LLM-assisted Home Assistant maintenance illustrate the accessibility of the software layer. They are not industrial safety precedents: plant environments add reliability, cybersecurity, environmental, and regulatory requirements.

7. The 110-year advantage is knowledge, not just data volume

For a manufacturer with 110+ years of operating history, the valuable archive may include drawings, test books, process deviations, rejected parts, field failures, repair records, and the reasons behind design rules. Not every company has such a history, and a century of operation does not automatically mean a century of clean, digitized data. But the accumulated knowledge can be exceptionally difficult for an external provider to reproduce.

Then there is tribal knowledge: the machinist who knows which fixture distorts a thin wall; the test engineer who recognizes a sensor artifact; the metallurgist who knows why a nominally acceptable heat-treatment cycle fails for one section thickness. Much of the competitive advantage lives in these exceptions, not in a generic process diagram.

A general-purpose commercial tool must serve many organizations. An internal solution can encode one company's machines, materials, failure modes, and accepted practice in far greater detail. That can make it better for a specific local problem than an off-the-shelf product or a consulting engagement without equivalent access. It is an advantage to demonstrate, not automatic superiority over every external specialist.

Turn institutional memory into something testable

Do not begin by training a foundation model from scratch. A practical first step is a curated, permission-aware knowledge system: approved documents and structured records retrieved with source citations, connected to deterministic calculators and analysis tools. Retrieval-augmented generation can expose the relevant evidence without relying on a model to memorize every detail.

• Preserve context: link records to part revision, machine, material batch, calibration, units, operating conditions, and approval status.
• Capture the reasoning: interview experienced staff with consent; record when a rule applies, why it exists, and what would invalidate it.
• Separate evidence from habit: mark measured results, validated procedures, hypotheses, and superseded practices differently. Seniority does not make every rule correct.
• Evaluate independently: hold out later production periods or different machines and product families as appropriate. Avoid putting near-duplicate records into both development and evaluation sets.
• Enforce permissions at retrieval: an assistant must not expose restricted customer programs or controlled technical data simply because they were indexed.

NIST's industrial AI work explicitly combines physics, data insights, and human observations, and emphasizes data provenance and domain-specific evaluation. That is a much stronger foundation than assuming a generic chatbot understands a factory because it can describe one. [8]

The earlier exploration of experimental data and missing physics points toward the same principle: physical evidence matters. Historical records can inform better correlations, surrogate models, and troubleshooting tools, but only after checking measurement quality and whether yesterday's conditions represent today's process.

Validated simulation archives belong in the same picture. Once a reviewed CFD or FEA workflow produces trustworthy results, its runs become training data for surrogate and reduced-order models: fast approximations that let engineers explore design options in seconds instead of queueing full analyses. The discipline is unchanged: document the training domain, measure prediction error on held-out cases, flag extrapolation, and revalidate when the product or process changes. A surrogate that silently leaves its validated envelope is a liability, not an asset.

Physics-informed models trained and validated on test data

Physics-informed ML models go one step further than surrogates trained on simulation output alone. Physics-informed neural networks embed the governing equations, conservation laws, and boundary conditions directly into training, then fit the remaining unknowns to experimental and test data: wind tunnel measurements, rig tests, field telemetry, and inspection records that already exist in company archives. The physics structure means they need far less data than a purely data-driven model, and they can capture real effects that a chosen simulation model misses, because the measurements carry the imprint of the true physics. [15]

The acceptance rules are the same as for any reduced-order model, applied to the test data rather than only to solver output: split measurements before training, validate against operating points and geometries the model has never seen, quantify error instead of eyeballing agreement, and treat correlation with new measurements as an ongoing obligation rather than a one-time milestone. LLMs can implement the data loaders, residual definitions, and training pipelines quickly; the measurement quality, physics priors, and acceptance criteria remain engineering decisions, as the earlier experimental-testing postmortem showed when a plausible pipeline produced confident, wrong intermediate outputs.

8. Less license dependence, not zero responsibility

LLM-assisted development makes it more feasible to move selected repetitive workloads onto open-source or in-house tools. That creates a credible path to relying less on expensive commercial seats and modules. It should not be confused with evidence that the entire industry has already abandoned commercial engineering software; the references here establish capabilities, not a market-wide migration rate.

Commercial codes can still earn their place through specialist physics, support, interoperability, established qualification evidence, and customer acceptance. Keep them where they provide value. Automate them through supported interfaces where that is the best option, and replace narrowly defined workflows only when the alternative meets the same acceptance criteria.

The comparison is total cost of ownership: licenses and external development versus compute, integration, validation, staff training, maintenance, security, and downtime risk. Open-source software removes some costs and restrictions, not the obligation to maintain a dependable system.

Self-sufficiency is therefore not “use nothing developed elsewhere.” Open-source projects, model developers, hardware suppliers, and consultants remain part of the ecosystem. It is the ability to inspect, adapt, maintain, and migrate the parts that matter, while owning the company's data, workflows, acceptance tests, and accumulated improvements.

Buy expertise where it adds value. Do not rent back your own engineering knowledge because nobody had time to build the interface.

9. Build a capability, not a collection of demos

A sensible starting point is one repeated, measurable task with a known answer: a post-processing report, a test-data import, or a read-only quality dashboard. Pair a domain engineer with reviewers who understand both the software and the plant systems it touches rather than handing an unrestricted agent the factory network.

1. Define the baseline. Measure current effort, error rate, turnaround, and cost. Set correctness and reliability criteria before generating code.
2. Bound the first tool. Use approved data, limited permissions, and a sandbox. Give it explicit inputs, outputs, and failure behavior.
3. Build with tests. Ask the LLM to work against known-good cases, boundary cases, and deliberate bad inputs. Review the code and dependencies, not just the demonstration.
4. Run in parallel. Compare the new workflow with the accepted one and independent evidence where needed. Record discrepancies; do not tune them away without understanding them.
5. Assign ownership. Name the engineering and software maintainers, retain change history, and rehearse recovery before wider deployment.
6. Scale what works. Share approved templates and components across teams. Measure time saved after review and maintenance, not merely code generated.

The limits of LLM-driven experimental testing remain relevant: a fluent explanation can conceal a bad measurement, a unit error, or an unjustified assumption. Faster implementation makes independent checks more valuable, not less.

What excites me is not a future in which engineering companies no longer need software expertise. It is one in which the people who understand the product and process can act on their knowledge directly, with software specialists supporting a much larger field of engineer-builders.

The durable asset is not the prompt or the model subscription. It is the growing library of validated workflows, usable company knowledge, and internal skills. That is how manufacturing companies become more self-sufficient: one owned, tested improvement at a time.

References & related reading

Primary sources for the model, software, and industrial-AI capabilities discussed above. The proposed workflows and business implications are engineering analysis, not reported results from these organizations.

1. Moonshot AI: Kimi K3 model cardOpen-weight multimodal agentic model: 1M-token context, long-horizon coding and reasoning, and the Kimi K3 License. Review the linked license for the exact terms: conditions apply to large Model-as-a-Service providers and high-reach commercial products, not ordinary internal use.
2. Z.AI: GLM-5.3 model cardGLM-5 series flagship for complex software engineering and long-horizon agent tasks, with a 1M-token context under the GLM-5.3 License. The efficient, natively multimodal GLM-5.3-Flash variant is released under the MIT license.
3. OpenFOAM documentation: Function objectsRuntime and post-processing operations, batch workflows, and reduced manual interaction. This reference is for the OpenCFD v2606 documentation; match instructions to the installed distribution.
4. ParaView: Batch Python ScriptingPython automation, trace recording, and the pvpython and pvbatch execution environments.
5. CalculiX: A Free Software Three-Dimensional Structural Finite Element ProgramLinear and nonlinear FEA, static, dynamic and thermal capabilities, and source licensing.
6. OpenJS Foundation & contributors: About Node-REDFlow-based programming, reusable integrations, and edge deployment.
7. ROS-Industrial: Project descriptionManufacturing robotics, calibration and planning tools, standardized interfaces, and integration with industrial controllers.
8. NIST: Industrial Artificial Intelligence Management and MetrologyPhysics, human observations, heterogeneous data, provenance, and domain-centered evaluation of industrial AI.
9. The OpenFOAM Foundation: OpenFOAMThe Foundation distribution, its engineering scope, and CFD Direct's development and maintenance role. See also the Foundation's free software licence explanation for in-house customization and distribution obligations.
10. The OpenFOAM Foundation: Chemical and Process EngineeringDocumented multiphase, turbulence, particle, heat-transfer, reaction, meshing, and mesh-motion capabilities, plus the Process Engineering Consortium's support for development and testing.
11. CFD Direct: CFD SupportOptional professional support for complex CFD practice, physical models, meshing, numerics, parallelization, post-processing automation, and code customization.
12. EDF: Code_AsterOpen-source finite-element solver for mechanics, thermal analysis, and dynamics, with documented vibration-fatigue and damage operators and an industrial qualification process at EDF.
13. CSC: Elmer FEMOpen-source multiphysics FEM covering fluid dynamics, structural mechanics, heat transfer, acoustics, and electromagnetics, with demonstrated parallel scalability.
14. NASA Glenn Research Center: OpenMDAOOpen-source Python framework for systems analysis and multidisciplinary optimization: decomposed coupled models, analytic derivatives, and gradient-based or gradient-free optimization across large design spaces.
15. Raissi, Perdikaris & Karniadakis: Physics-informed neural networksThe foundational Journal of Computational Physics (2019) framework for solving forward and inverse problems by embedding nonlinear PDEs in deep-learning training, including learning from scattered experimental measurements.

Continue with the OpenFOAM demonstration, why mature engineering tools should not be dismissed, or where the LLM still needs a human.