Using a Feedback Loop for LLM-based Infrastructure as Code Generation

Mark Santolucito; Mayur Amarnath Palavalli

REVIEW 4 major objections 7 minor 1 cited by

Using a Feedback Loop for LLM-based Infrastructure as Code Generation

T0 review · 4 major / 7 minor · reviewed 2026-08-12 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read Feeding lint errors back to an LLM improves cloud templates only until roughly iteration five.

desk verdict A small but honest empirical study of cfn-lint feedback for LLM-generated CloudFormation; the plateau is plausible, but the 'exponential' claim outruns the statistics. read the letter →

arxiv 2411.19043 v1 pith:YYWKGOZL submitted 2024-11-28 cs.SE cs.AI

Mayur Amarnath Palavalli , Mark Santolucito This is my paper · ORCID

classification cs.SEcs.AI

keywords InfrastructureasCodeLLMgenerationCloudFormationcfn-lintfeedbacklooplinterrorcorrection

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper asks whether an LLM can write usable AWS CloudFormation infrastructure if it is allowed to see and respond to a linter's error messages. The authors built a benchmark from 33 real CloudFormation problem descriptions, generated 165 templates, and ran a loop in which cfn-lint errors and warnings are returned to the model for ten rounds, repeated six times. They report that the total error count drops quickly in the first few rounds and then flattens by about the fifth round, so further feedback no longer produces net improvement. The authors describe the per-iteration effectiveness as decreasing exponentially until it plateaus. The point matters because it puts a concrete bound on a common strategy for using LLMs in infrastructure management: lint-feedback alone is a limited, front-loaded tool, and it does not address whether the generated infrastructure actually does what the prompt asked.

What carries the argument

The central object is the feedback loop itself: a prompt describing infrastructure is given to an LLM, the resulting CloudFormation JSON template is run through cfn-lint, and the returned error and warning messages are appended to the prompt for the next generation. cfn-lint is a linter that validates CloudFormation templates against AWS resource-provider schemas and best-practice rules. The loop's output is a per-iteration count of total errors and warnings over all benchmark files; that count, plotted against iteration number, is the quantity that carries the paper's exponential-decay and plateau argument.

What would settle it

Continue the feedback loop beyond ten iterations on the same 165 templates; if the aggregate cfn-lint error count keeps decreasing after iteration ten, the claimed plateau at five is not a true floor.

Watch

Extended reading notes

Core claim

The central claim is that the cfn-lint feedback loop is effective only for a limited number of iterations. Across 165 CloudFormation templates, each run through ten feedback rounds and the whole process repeated six times, the aggregate number of cfn-lint errors and warnings falls during the first rounds and reaches a plateau at roughly the fifth iteration; from that point the loop is, in the authors' words, no longer effective. The plateau appears because the LLM is inconsistent in fixing errors: a repaired error occasionally spawns several new errors, and the model cannot fully reconcile the lint messages with the high-level intent of the original prompt. The paper also reports a slight rise in errors at iterations eight and nine, indicating that continuing the loop can sometimes make the aggregate result worse.

Load-bearing premise

The load-bearing premise is that the number of cfn-lint errors and warnings is an adequate measure of generated IaC quality, since that same count is both the feedback the model receives and the metric used to declare the loop ineffective.

Editorial extensions

If this is right

A naive lint-feedback loop yields most of its improvement within the first five iterations, so additional rounds of the same feedback add little value.
Repeated lint feedback is not monotonic: aggregate errors can increase at later iterations, so blindly looping more can degrade generated IaC.
LLM-generated CloudFormation remains far from being schematically valid at scale, and the authors identify semantic validity as an open problem beyond what cfn-lint can check.
The same feedback-loop design can serve as a baseline for future work on structured feedback or grammar-constrained decoding, which the paper leaves to future work.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

A testable extension would be to replace raw cfn-lint messages with structured or grouped feedback; if the plateau shifts or disappears, the limit is in the message format rather than in the LLM itself.
Because cfn-lint's error count is both the signal and the measure, the paper's 'becomes ineffective' should be read as 'stops reducing lint errors'; whether the generated infrastructure deploys or matches user intent is not measured.
The same loop applied to less-documented IaC tools such as Pulumi or Terraform would likely plateau at a higher error level, since the model has less training data to draw on; the authors only speculate about this.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

The useful thing here is the dataset and the plateau observation. They built 33 CloudFormation prompts from the AWS schema repository, generated 165 templates, and ran a cfn-lint feedback loop for ten iterations, repeated six times. The code and results are open source. The finding that aggregate error counts drop quickly and then flatten around iteration five is concrete and, as far as the cited related work goes, new for IaC. The paper also honestly flags the semantic-validity gap and the risk of using a different model. That is real, reproducible work and deserves credit.

The soft spots are all in the gap between the evidence and the headline claim. The abstract and Section 5 say the effectiveness "decreases exponentially until it plateaus," but there is no fitted exponential, no per-iteration table, no confidence intervals, and no significance test comparing iteration 5 against iteration 10. The bars show a rise at iterations 8 and 9, which a monotone exponential does not explain. The plateau could simply be an aggregate artifact: the authors themselves say the loop fixes some errors while introducing new ones, so the flat count may hide ongoing per-file churn. Without a per-file paired test or a segmented model, "becomes ineffective" is too strong. Also, the model is only named in passing in the discussion, and there is no zero-shot or one-shot baseline, so the marginal value of repeated feedback is not actually quantified.

Those are fixable issues, not fatal ones. The circularity concern is low, as the reader notes: using cfn-lint for both feedback and evaluation is a natural design choice, and the count could have kept declining. The paper is a solid empirical starting point, not a definitive result.

Who is this for? Researchers building agentic IaC tooling, or anyone deciding when to stop iterating on LLM-generated templates. It deserves a serious referee, but the authors should be pushed to report the underlying numbers, run a significance test, name the model in the methodology, and replace "exponential" with a description the data actually supports.

Recommendation: send to peer review, but the revision must address the statistical support for the plateau and the model/baseline details.

Referee Report

4 major / 7 minor

Summary. The paper investigates whether an LLM can improve generated AWS CloudFormation infrastructure code through a feedback loop that feeds cfn-lint error and warning messages back into the model. The authors build a benchmark from 33 AWS CloudFormation example descriptions, generate 165 initial templates, and run up to ten feedback iterations, repeating the full process six times. The central claim, stated in the abstract and Section 5, is that the loop's effectiveness decreases exponentially and plateaus around the fifth iteration, after which additional feedback no longer helps. The paper also discusses threats to validity and proposes future work, including semantic-validity checking and alternative feedback strategies.

Significance. If the exponential/plateau claim were statistically established, the paper would provide a useful data point for the IaC-generation community: it would quantify the limits of LLM self-correction on linter feedback and motivate alternative designs such as grammar-constrained decoding or more structured error messages. The paper contributes an open-source benchmark and evaluation harness, which is a concrete strength that supports verification and reuse. However, the central quantitative claim currently rests on visual inspection of a single bar chart, with no fitted models, no tabulated statistics, and no significance tests. The chosen metric—aggregate cfn-lint error/warning count—also constrains the conclusion to static, linter-detectable properties, not semantic or deployable correctness. The paper is better viewed as a preliminary empirical report than as a rigorous evaluation, and the claims need to be scaled back or backed by additional analysis.

major comments (4)

[Section 5, Fig. 5] The claim that effectiveness "decreases exponentially until it plateaus" at approximately the fifth iteration is not supported by any quantitative analysis. The paper reports no tabulated per-iteration means, standard deviations, or per-iteration deltas; it fits no exponential or segmented plateau model; and it runs no significance test comparing iterations around the putative plateau. In fact, the aggregate count rises at iterations 8 and 9 (Section 5, items (1) and (2)), which is inconsistent with a monotone exponential decay; the authors offer a qualitative explanation but do not test whether these rises are noise or systematic. Please provide the underlying statistics and a formal test (e.g., paired per-file comparisons between iterations 5 and 10, or a segmented regression) before making the exponential/plateau conclusion.
[Sections 4.2 and 5] The operational definition of "effectiveness" is the same cfn-lint error/warning count that is used as the feedback signal. The finding is therefore necessarily about how well the model reduces cfn-lint-detectable static problems, not about whether the generated templates are deployable or semantically correct. The paper itself acknowledges in Section 6 that semantic validity is unmeasured, but the abstract and conclusion phrase the result more strongly, stating that the feedback loop "becomes ineffective." The claims should be qualified to the chosen metric, or an additional evaluation (e.g., template deployment checks or manual semantic review) should be added.
[Section 4.2] The statistical design is underspecified. It is unclear whether the six repetitions are independent re-runs over the same 165 initial templates or over newly sampled templates; the LLM is not named in the methodology (it appears only in Section 6.1); and no sampling parameters such as temperature are reported. This ambiguity matters because the error bars in Fig. 5 are the only evidence of stability, and the paper's justification for stopping at six repetitions ("most of the error bars are narrow") is not backed by reported values. Please clarify the trial structure and report the actual per-iteration means and standard deviations.
[Section 5] The authors attribute the plateau to the loop fixing some errors while introducing new ones, but no per-file or per-error-type analysis is presented to distinguish a true plateau from aggregate churn. If individual files continue to improve while others degrade, the aggregate count may be flat even though the feedback loop remains effective for some error classes. A per-file paired comparison across iterations (e.g., iterations 5 vs. 10) or an error-type breakdown is needed to support the conclusion that the loop is "no longer effective" at the individual-file level.

minor comments (7)

[Sections 1 and 3] cfn-lint is cited as [3] in the introduction and as [4] in the Background, while the reference list assigns [3] to the cfn-lint GitHub repository and [4] to a different tool (aiac); please unify the citations.
[Section 4.2 heading] The heading "Feeback Loop" contains a typo; it should be "Feedback Loop."
[Section 6] The sentence "Automating the generation of CloudFormation templates could drastically increases the speed" should read "could drastically increase the speed," and "scale-able" should be "scalable."
[Section 4.2] The relationship between the 33 descriptions, the 5 queries per description, and the 6 repetitions should be stated precisely; the current text leaves it ambiguous whether the 165 files are the initial generation set or the unit over which the 10-iteration process is repeated six times.
[Front matter] The ACM template placeholders (conference title placeholder, year 2018, and DOI XXXXX) should be removed before submission.
[Abstract and Section 5] The phrase "for each iteration of the loop, its effectiveness decreases exponentially" conflates the marginal per-iteration improvement with the total error count; please define "effectiveness" explicitly, for example as the reduction in error count from iteration i to iteration i+1.
[Section 6] The paper does not report a no-feedback or iteration-0 baseline, so the statement that the feedback loop "dramatically increases the chance of generating valid IaC" is not directly supported by the presented data; a comparison against zero-shot generation without feedback would strengthen this claim.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the cfn-lint error count is both feedback and metric, but the plateau is a contingent empirical result, not a construction.

full rationale

The paper's central claim is an empirical observation about how aggregate cfn-lint error counts evolve across feedback iterations. Although cfn-lint supplies both the feedback messages and the measured outcome, this does not make the result true by construction: the loop could have continued reducing the count, and the paper reports that it instead plateaus, which is a contingent finding. The authors also explicitly separate schematic validity from semantic validity in Section 6, acknowledging that the metric is narrow. There is no fitted parameter renamed as a prediction, no uniqueness theorem, and no load-bearing self-citation; references to the authors' prior work in Section 1 and references [15, 18] are background. The exponential/plateau claim may be statistically under-supported because the results section offers no fitted model or significance test, but that is an evidentiary weakness, not circularity.

Assumptions & free parameters 3 free parameters · 4 assumptions · 0 invented entities

The paper introduces no new physical or mathematical entities. It builds a benchmark and a feedback loop from existing tools (cfn-lint, an LLM, AWS CloudFormation). The free parameters listed are hand-set experimental design choices, not fitted constants in a model.

free parameters (3)

Feedback iteration cap = 10
Hand-set at ten rounds; the plateau claim at round five requires the loop to run past the plateau point.
Independent trials = 6
Chosen because error bars appeared narrow; no power analysis, so the stability claim is an assumption.
Templates per prompt = 5
Each of 33 prompts was sampled five times; aggregate counts treat these as exchangeable.

assumptions (4)

domain assumption cfn-lint error count is an adequate proxy for IaC correctness
cfn-lint is used both as feedback and as the evaluation metric (Sec 4.2, Fig 5), so the central claim is about reducing this count, not about deployability or semantic validity.
domain assumption The 33 AWS CloudFormation Template Schema descriptions are representative of real-world IaC tasks
Section 4.1 selects prompts from one public repository; there is no sampling strategy, diversity analysis, or external validation.
domain assumption The unstated LLM (apparently gpt-4o) is representative of current code LLMs
Section 6.1 generalizes to other LLMs, but only one model is tested and it is never named in the methodology.
domain assumption Six repetitions of the ten-round loop give stable aggregate counts
Section 4.2 justifies six trials by narrow error bars; this is not a formal statistical test.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Using a Feedback Loop for LLM-based Infrastructure as Code Generation." pith.science (2026). https://pith.science/paper/YYWKGOZL

@misc{pith2026241119043,
  author       = {Pith},
  title        = {Pith review of: Using a Feedback Loop for LLM-based Infrastructure as Code Generation},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/YYWKGOZL}},
  note         = {Machine review of arXiv:2411.19043}
}

read the original abstract

Code generation with Large Language Models (LLMs) has helped to increase software developer productivity in coding tasks, but has yet to have significant impact on the tasks of software developers that surround this code. In particular, the challenge of infrastructure management remains an open question. We investigate the ability of an LLM agent to construct infrastructure using the Infrastructure as Code (IaC) paradigm. We particularly investigate the use of a feedback loop that returns errors and warnings on the generated IaC to allow the LLM agent to improve the code. We find that, for each iteration of the loop, its effectiveness decreases exponentially until it plateaus at a certain point and becomes ineffective.

Figures

Figures reproduced from arXiv: 2411.19043 by the authors.

**Figure 1.** An example AWS CloudFormation JSON template. [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗

**Figure 2.** An example error message from cfn-lint. In this work, we focus solely on the LLM generation of AWS CloudFormation [9] in JSON. We additionally use the AWS CloudFormation linter cfn-lint [4]. cfn-lint allows us to validate CloudFormation JSON templates against the resource provider schemas provided by AWS as well as other best-practice IaC rules. A schematically valid JSON template returns nothing when run throug… view at source ↗

Figures from the paper (1 more)

**Figure 5.** Figure 5: A histogram of errors over multiple [PITH_FULL_IMAGE:figures/full_fig_p003_5.png]

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

Does Fixing Break Security? An Empirical Study of Security Degradation in Iterative LLM-Driven Infrastructure-as-Code Repair
cs.SE 2026-08 conditional novelty 6.0 of 10

Iterative LLM repair of Terraform code causes a security regression in about 3.3% of scenarios under strict counting, most often through resource restructuring, with iteration 3 as the recommended stopping point.

Reference graph

Works this paper leans on

21 extracted references · 11 canonical work pages · cited by 1 Pith paper

[1]

https://www.pulumi.com/docs/, [Accessed 12-09- 2024]

Documentation — pulumi.com. https://www.pulumi.com/docs/, [Accessed 12-09- 2024]

work page 2024
[2]

https://github.com/aws- cloudformation/aws-cloudformation-templates, [Accessed 02-09-2024]

GitHub - aws-cloudformation/aws-cloudformation-templates: A collection of useful CloudFormation templates — github.com. https://github.com/aws- cloudformation/aws-cloudformation-templates, [Accessed 02-09-2024]

work page 2024
[3]

https://github.com/aws-cloudformation/cfn-lint?tab=readme-ov-file, [Accessed 12-09-2024]

GitHub - aws-cloudformation/cfn-lint: CloudFormation Linter — github.com. https://github.com/aws-cloudformation/cfn-lint?tab=readme-ov-file, [Accessed 12-09-2024]

work page 2024
[4]

— github.com

GitHub - gofireflyio/aiac: Artificial Intelligence Infrastructure-as-Code Generator. — github.com. https://github.com/gofireflyio/aiac, [Accessed 02-09-2024]

work page 2024
[5]

It is a source-available tool that codifies APIs into declarative configuration files that can be shared amongst team members, treated as code, edited, reviewed, and versioned

GitHub - hashicorp/terraform: Terraform enables you to safely and predictably create, change, and improve infrastructure. It is a source-available tool that codifies APIs into declarative configuration files that can be shared amongst team members, treated as code, edited, reviewed, and versioned. — github.com. https://github.com/hashicorp/terraform, [Acc...

work page 2024
[6]

https://github.com/pulumi/pulumi-ai, [Accessed 12-09-2024]

GitHub - pulumi/pulumi-ai — github.com. https://github.com/pulumi/pulumi-ai, [Accessed 12-09-2024]

work page 2024
[7]

https://arxiv.org/abs/2305.13971, [Accessed 25-10-2024]

Grammar-Constrained Decoding for Structured NLP Tasks without Finetuning — arxiv.org. https://arxiv.org/abs/2305.13971, [Accessed 25-10-2024]

arXiv 2024
[8]

https://openai.com/index/introducing- structured-outputs-in-the-api/, [Accessed 02-09-2024]

Introducing Structured Outputs in the API. https://openai.com/index/introducing- structured-outputs-in-the-api/, [Accessed 02-09-2024]

work page 2024

Show all 21 references

[9]

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/ Welcome.html, [Accessed 02-09-2024]

What is AWS CloudFormation? - AWS CloudFormation — docs.aws.amazon.com. https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/ Welcome.html, [Accessed 02-09-2024]

2024
[10]

IT Faculty

Cauli, C.: Pre-deployment description logic-based reasoning for cloud infrastruc- ture security (2022), University of Gothenburg. IT Faculty. Dissertation

2022
[11]

Chen, M., Tworek, J., Jun, H., Yuan, Q., de Oliveira Pinto, H.P., Kaplan, J., Edwards, H., Burda, Y., Joseph, N., Brockman, G., Ray, A., Puri, R., Krueger, G., Petrov, M., Khlaaf, H., Sastry, G., Mishkin, P., Chan, B., Gray, S., Ryder, N., Pavlov, M., Power, A., Kaiser, L., Ba...

2021 arXiv
[12]

In: 2022 IEEE 19th International Conference on Software Archi- tecture Companion (ICSA-C)

Chiari, M., De Pascalis, M., Pradella, M.: Static analysis of infrastructure as code: a survey. In: 2022 IEEE 19th International Conference on Software Archi- tecture Companion (ICSA-C). pp. 218–225 (2022). https://doi.org/10.1109/ICSA- C54293.2022.00049

2022
[13]

In: 2019 IEEE In- ternational Conference on Software Maintenance and Evolution (ICSME)

Guerriero, M., Garriga, M., Tamburri, D.A., Palomba, F.: Adoption, support, and challenges of infrastructure-as-code: Insights from industry. In: 2019 IEEE In- ternational Conference on Software Maintenance and Evolution (ICSME). pp. 580–589 (2019). https://doi.org/10.1109/ICS...

2019
[14]

Jimenez, C.E., Yang, J., Wettig, A., Yao, S., Pei, K., Press, O., Narasimhan, K.: Swe- bench: Can language models resolve real-world github issues? arXiv preprint arXiv:2310.06770 (2023)

2023 arXiv
[15]

In: Groote, J.F., Larsen, K.G

Lepiller, J., Piskac, R., Schäf, M., Santolucito, M.: Analyzing infrastructure as code to prevent intra-update sniping vulnerabilities. In: Groote, J.F., Larsen, K.G. (eds.) Tools and Algorithms for the Construction and Analysis of Systems. pp. 105–123. Springer International ...

2021
[16]

Opdebeeck, R., Zerouali, A., De Roover, C.: Control and data flow in security smell detection for infrastructure as code: Is it worth the effort? In: 2023 IEEE/ACM 20th International Conference on Mining Software Repositories (MSR). pp. 534–545 (2023). https://doi.org/10.1109/...

2023
[17]

Park, K., Wang, J., Berg-Kirkpatrick, T., Polikarpova, N., D’Antoni, L.: Grammar- aligned decoding (2024), https://arxiv.org/abs/2405.21047

2024
[18]

arXiv preprint arXiv:2402.15632 (2024)

Qiao, F., Mohammadi, A., Cito, J., Santolucito, M.: Statically inferring usage bounds for infrastructure as code. arXiv preprint arXiv:2402.15632 (2024)

2024 arXiv
[19]

arXiv preprint arXiv:2404.00227 (2024), https://arxiv.org/abs/2404.00227

Srivatsa, K.G., Mukhopadhyay, S., Katrapati, G., Shrivastava, M.: A survey of using large language models for generating infrastructure as code. arXiv preprint arXiv:2404.00227 (2024), https://arxiv.org/abs/2404.00227

2024 arXiv
[20]

arXiv preprint arXiv:2311.16543 (2023), https://arxiv.org/ abs/2311.16543

Tsai, Y., Liu, M., Ren, H.: Rtlfixer: Automatically fixing rtl syntax errors with large language models. arXiv preprint arXiv:2311.16543 (2023), https://arxiv.org/ abs/2311.16543

2023 arXiv
[21]

Ugare, S., Suresh, T., Kang, H., Misailovic, S., Singh, G.: SynCode: LLM generation with grammar augmentation (2024), https://arxiv.org/abs/2403.01632 Received 20 February 2007; revised 12 March 2009; accepted 5 June 2009

2024 arXiv

Pith tools

Reviewed August 12, 2026 · model on record in the stance chip above.

[1] [1]

https://www.pulumi.com/docs/, [Accessed 12-09- 2024]

Documentation — pulumi.com. https://www.pulumi.com/docs/, [Accessed 12-09- 2024]

work page 2024

[2] [2]

https://github.com/aws- cloudformation/aws-cloudformation-templates, [Accessed 02-09-2024]

GitHub - aws-cloudformation/aws-cloudformation-templates: A collection of useful CloudFormation templates — github.com. https://github.com/aws- cloudformation/aws-cloudformation-templates, [Accessed 02-09-2024]

work page 2024

[3] [3]

https://github.com/aws-cloudformation/cfn-lint?tab=readme-ov-file, [Accessed 12-09-2024]

GitHub - aws-cloudformation/cfn-lint: CloudFormation Linter — github.com. https://github.com/aws-cloudformation/cfn-lint?tab=readme-ov-file, [Accessed 12-09-2024]

work page 2024

[4] [4]

— github.com

GitHub - gofireflyio/aiac: Artificial Intelligence Infrastructure-as-Code Generator. — github.com. https://github.com/gofireflyio/aiac, [Accessed 02-09-2024]

work page 2024

[5] [5]

It is a source-available tool that codifies APIs into declarative configuration files that can be shared amongst team members, treated as code, edited, reviewed, and versioned

GitHub - hashicorp/terraform: Terraform enables you to safely and predictably create, change, and improve infrastructure. It is a source-available tool that codifies APIs into declarative configuration files that can be shared amongst team members, treated as code, edited, reviewed, and versioned. — github.com. https://github.com/hashicorp/terraform, [Acc...

work page 2024

[6] [6]

https://github.com/pulumi/pulumi-ai, [Accessed 12-09-2024]

GitHub - pulumi/pulumi-ai — github.com. https://github.com/pulumi/pulumi-ai, [Accessed 12-09-2024]

work page 2024

[7] [7]

https://arxiv.org/abs/2305.13971, [Accessed 25-10-2024]

Grammar-Constrained Decoding for Structured NLP Tasks without Finetuning — arxiv.org. https://arxiv.org/abs/2305.13971, [Accessed 25-10-2024]

arXiv 2024

[8] [8]

https://openai.com/index/introducing- structured-outputs-in-the-api/, [Accessed 02-09-2024]

Introducing Structured Outputs in the API. https://openai.com/index/introducing- structured-outputs-in-the-api/, [Accessed 02-09-2024]

work page 2024