Systematic Style Replication with LLMs: The Style Tool#

1. Experimental Context and Motivation#

1.1 Initial Situation#

The Style Tool arose from a discussion about the possibilities of large language models. Since LLMs are essentially tools for working with language, the question arose: To what extent can LLMs copy and imitate language and writing styles? The question seemed interesting enough to explore its feasibility in broad terms.

The idea that writing and language styles could also be replicated for more complex styles seemed fascinating. Simple prompts can already be used to create style prompts that imitate a general style. However, styles are more than just sentence structure: they also structure differently and have very different narratives, sequences, and processes.

The project was conceived as a learning vehicle to find out how well this more comprehensive style replication works.

2. The tool: How it works and its structure#

Style is a Gradio-based web application for the systematic development and application of style transformation prompts. The application is divided into four main functional areas (tabs).

2.1 Tab 1: Transform#

This area converts texts according to defined style profiles. Users can import style profiles in three ways:

  • Selection from stored profiles (four built-in profiles: Academic University, LinkedIn Post, Technical Documentation, Customer Email)
  • Upload your own profiles (JSON or ZIP)
  • Direct entry of a prompt

Source texts can be uploaded as files or inserted directly. Supported formats are TXT, Markdown, and DOCX. A token count shows the input size and warns if limits are exceeded.

After transformation, the result can be edited. A feedback function enables iterative refinement: the transformed text can be transformed again with additional instructions.

Export options include various formats (TXT, MD, DOCX) and either the transformation only or both versions (original and transformed).

2.2 Tab 2: Analyze style#

This function systematically extracts stylistic features from sample texts. The analysis is carried out in four dimensions:

Linguistic features: Sentence length (average and variance), sentence complexity, passive-active ratio, nominal style score, hedging level, connector types

Lexical features: Technical terminology density, proportion of foreign words, degree of abstraction, modal verb frequency

Pragmatic features: Degree of formality, reader address, objective, target group

Structural features: Paragraph length, heading hierarchy, list frequency, text structure

Users can upload their own texts (source style). Optionally, either target texts (examples of the desired style) or a textual description of the target style can be specified.

The LLM analyzes the texts and structures the results. The analysis can be exported as a JSON profile, prompt text, or complete ZIP package. The LLM automatically converts the natural language analysis into structured JSON format.

2.3 Tab 3: Fine-tuning#

This area implements a diff-based approach to profile refinement. The idea is to fine-tune the resulting texts by making changes that are then tracked. This pattern corresponds to common practice—you get answers from the AI and then adjust them.

The workflow:

  1. Optional: Load a base profile (stored or uploaded)
  2. Enter an original text (left column)
  3. Enter or create the edited version (right column)
  4. Analysis of change patterns by the LLM

The LLM analyzes systematic differences between the original and the edited version and derives transformation rules from them. If a base profile is available, these rules are used to refine the profile.

Up to five before-and-after pairs can be processed. The accumulated findings are incorporated into a refined profile that can be exported as a ZIP package.

A help function allows the right column to be pre-filled with an automatic transformation based on the loaded base profile.

2.4 Tab 4: Style overview#

This area visualizes style profiles. After loading a profile (stored or uploaded), the features are displayed with Unicode bar charts. The generated transformation prompt is displayed in full and can be copied.

3. Technical architecture#

3.1 Overall structure#

The application comprises 2140 lines of Python code in six files. The main application (app.py) contains 1200 lines and orchestrates the entire UI logic and tab functions. In addition, there are prompt templates and JSON profiles, so that the entire project comprises about 4000 lines, about half of which is Python and the rest prompts and configuration files.

3.2 Modules#

llm_client.py: Encapsulates the LLM API integration. Uses an OpenAI-compatible interface to the LLM of Humboldt University Berlin. Implements token counting with Tiktoken, supports a context window of 250,000 tokens, and reserves 50,000 tokens for responses. Contains three main functions: analyze_style() for style extraction, transform_text() for transformations, and analyze_diff() for before-and-after comparisons.

document_processor.py: Processes various document formats. Converts DOCX to Markdown while retaining structure (headings, lists, tables). Loads TXT and Markdown directly. Saves in all three formats. Validates files for format and size (maximum 10 MB).

profile_manager.py: Manages style profiles. Loads built-in profiles from the profiles directory. Imports external profiles from JSON or ZIP. Extracts prompts from profiles or generates them from structured data. Creates empty profile templates with the complete structure of the four dimensions (linguistics, lexis, pragmatics, structure).

export_handler.py: Handles all export operations. Creates JSON files, prompt texts, ZIP packages, and transformed documents. Uses tempfile.NamedTemporaryFile for Gradio-compatible downloads. ZIP packages contain stil_parameter.json, stil_prompt.txt, and stil_beispiele.txt.

3.3 Prompt Templates#

Three separate template files define the system prompts:

style_analysis.txt: Instructs the LLM to systematically extract style features in the four dimensions. Requests quantitative information where possible and extracts 20-30 representative example sentences.

style_transformation.txt: Defines the transformation task. Instructs the model to retain content substance while adapting form and tone according to the style profile.

diff_analysis.txt: Instructs the model to perform a comparative analysis between the original and the edited text. Requests identification of systematic change patterns, quantification where possible, and derivation of transformation rules.

3.4 The hybrid approach#

A key architectural feature is the combination of structured JSON data and natural language prompts. Style profiles contain:

{
  “linguistics”: {
    “sentence_length”: {‘average’: 18, “variance”: 5}
  },  “generated_prompt”: “Write in academic style...”
}

This approach enables both machine processing (for visualization, comparisons) and flexible linguistic instructions (for transformation). The mixture had already proven beneficial in other experiments.

4. Development process#

4.1 Methodological approach#

The development followed a structured process. Initially, it was not clear what the implementation would look like. Through intensive interaction to exchange solutions, a clearer picture emerged – especially with regard to the division into functional areas (tabs).

During this discussion, it became clear that JSON could serve as a possible import/export format. The modular architecture developed during this specification phase.

The idea was not only to derive styles from input texts, but also to be able to give instructions on what else should be taken into account. In addition, it should be possible to fine-tune the resulting texts by making changes that are tracked. The aim here was purely to try out the idea and the approach using changes (diffs).

4.2 Specification before implementation#

Only after the specification, the technical approaches, and the architecture were completely clear did implementation take place. When coordinating the specification, close attention was paid to KISS principles in order to obtain a simple, good solution.

The quality of the specification proved to be crucial: the higher the quality of the specification process and the specification, the better the idea could be implemented. Architectural experience was very important in this regard.

4.3 Implementation and iterations#

The high-quality, complete specification enabled direct implementation. There was only one iteration, as the specification was very detailed and could be implemented in its entirety.

Time required:

  • Specification and initial implementation, including coding and deployment: approximately 90 minutes
  • Two subsequent small iterations for error corrections: 30 minutes each

In total, about 2.5 hours were spent on the functioning application.

4.4 Technology stack#

An LLM from Humboldt University Berlin was used for operation. The choice of Gradio as the UI framework was based on previous positive experiences from earlier projects.

The hybrid approach (JSON + natural language) was also familiar from other experiments and was consistently applied here. Token management as a standard pattern was adopted from previous projects.

5. Validation and findings#

5.1 Test phase#

The tool is currently being tested. Initial tests show that it works very well. So far, about ten style profiles have been created.

5.2 Replicable styles#

The range of successfully replicated styles is remarkable:

Author styles: Literary styles such as Goethe’s can be replicated.

Speech styles: Political speech styles work particularly well. Both Helmut Schmidt and Barack Obama could be replicated as styles.

Genres: Different types of text such as interviews or comics can be replicated.

5.3 The comic case#

The comic style works particularly well and illustrates a practical application. The tool not only generates dialogue in comic language, but also describes individual panels for comics.

This linguistic basis works very well. The generated texts could then be converted into graphic comics using a diffusion model (in other tools). The style tool provides the structured textual basis, which is then further processed visually.

5.4 Key finding#

The most surprising observation: style is apparently a cultural phenomenon and not just a linguistic one – but it can still be replicated.

This finding goes beyond the original expectation. Styles encompass not only linguistic patterns, but also cultural conventions, contexts, and expectations. The fact that LLMs appear to be able to capture and reproduce this cultural dimension is remarkable.

The possibilities appear very impressive. So far, they seem to be very far-reaching.

6. Methodological findings#

6.1 Specification quality as a lever for efficiency#

The key transferable finding: The higher the quality of the specification process and the specification, the better the idea can be implemented. Architectural experience is very important in this regard.

The 90-minute development was only possible thanks to:

  • Intensive clarification prior to implementation
  • Complete specification of all functions and interfaces
  • Consistent application of KISS principles already in the specification phase
  • Transfer of proven patterns from previous projects

6.2 Proven technical patterns#

Several techniques have proven themselves:

Token management: The implementation of token counting and proactive warnings is now standard in all tools. This technique was consistently adopted after previous projects.

JSON structuring: The automatic conversion of natural language LLM outputs into structured JSON worked well from the start. This technique was already known from other tool developments.

Hybrid approach: The combination of linguistic instructions to the LLM and structured information via JSON has proven to be beneficial in the past. This approach is considered elegant.

6.3 The diff-based approach#

Diff analysis for fine-tuning works quite well, but needs to be explored further. The approach is interesting because it reflects real work patterns: humans often manually adjust AI outputs. Systematizing these adjustments into transformation rules could have practical value.

6.4 Project size and manageability#

The project was small in size and very manageable:

  • Total scope: 4000 lines
  • Python code: 2000 lines in only 6 files
  • Rest: prompts and configurations
  • Main application: 1200 lines

This size allowed for complete overview and rapid development. The deliberate limitation through KISS principles contributed to this.

7. Transferable principles#

Several principles for LLM-supported development can be derived from this experiment:

1. Specification before implementation: Invest time in fully clarifying all aspects before coding. Dialogue and discussion are more valuable than early coding.

2. Architectural experience remains important: LLMs can implement specified architectures, but the architecture itself requires human judgment and project experience.

3. KISS in the specification phase: Complexity must be limited early on. Explicit simplicity constraints prevent overengineering more effectively than later refactoring.

4. Transfer proven patterns: Successful technical approaches from previous projects should be consistently reused (token management, hybrid approach, JSON structuring).

5. Small, manageable projects: Limiting the project to around 2000 lines of Python code increases clarity and development speed.

6. Explore experimental approaches: New ideas such as diff-based refinement can be tried out, even if they are not yet fully mature.

8. Conclusion#

The style tool demonstrates that LLM-supported development can be highly efficient when approached methodically. 90 minutes for a complete, functional tool is realistic with high-quality specifications.

The insight that style is a cultural phenomenon and that LLMs can apparently capture this dimension is remarkable. The test results so far show an impressive range of replicable styles, from literary authors and speakers to genres such as comics.

The diff-based fine-tuning approach is innovative and reflects real work processes. It needs to be explored further, but shows potential.

For the practice of LLM-supported development, the key message is: specification quality is the decisive lever for efficiency. The combination of clear architecture, KISS principles, and the transfer of proven patterns enables extremely fast implementations.

Backward Style-Tool Style Tool Short Forward