As a part of attending to grips with the brand new world of agentic engineering,
\nI constructed an utility to help my work. It\u2019s a classy app:
\nhigh-quality internet UI with dynamic refresh and look-up, modals and
\nauto-save, integrations to exterior methods, machine studying and textual content
\nevaluation, background jobs, and a correct atmosphere setup with totally
\nautomated deployment. It\u2019s roughly 150,000 strains of code,
\nprimarily in Rust (~120 kLoC) with the rest in TypeScript and
\nTerraform.<\/p>\n

This was totally written by brokers. Largely Claude Code, and a few use
\nof Cursor. I didn\u2019t learn or evaluate any of the code, besides
\noften, out of curiosity.<\/p>\n

Whereas constructing the applying, I may see some issues going
\nawry. After watching an edit to line 4,000 of a file scroll by within the
\nterminal, I had a more in-depth look. The info entry layer had grown to over
\n6,000 strains. As extra options landed, this continued to
\ndevelop. Each question, learn or write, repeated the identical HTTP request
\nsetup, the identical JSON encoding and decoding. Finally, it reached 17,155
\nstrains. In a single Rust file.<\/p>\n

An experiment in refactoring<\/h2>\n

The 17,155 line file was your entire knowledge entry layer. A single,
\nself-contained module. Reviewing the code, there was no
\nde-duplication, no inner language, restricted extraction of capabilities,
\nand little or no extraction of lessons. It did have a transparent boundary
\nwith an interface to protect. It was an important goal for refactoring.<\/p>\n

The aim of refactoring an agentic code base is to spend tokens now in
\nrefactoring to make token consumption for future work decrease. An
\nexperiment ought to be capable to present that as this file was refactored the
\ntoken value of creating separate characteristic implementations on this code
\nbase would lower.<\/p>\n

Exactly as a result of brokers by no means be taught this was now doable to run as
\nan experiment. I may immediate a recent agent to make precisely the identical
\nchange after each refactoring stage. In contrast to a human engineer, the
\nexperiment wouldn’t be tainted by studying from earlier steps.<\/p>\n

In a loop:\n

Report all token prices, time to execute the change, and features of
\ncode after every step of the refactoring, together with the baseline.<\/li>\n<\/ol>\n
The immediate used for the consultant change and the refactoring
\nsteps utilized are proven within the appendices, under.<\/p>\n
One caveat: Claude doesn\u2019t present dependable strategies for counting
\ntokens reside regardless of exhibiting token counts, reporting tokens consumed
\nper session, and billing<\/strong> for tokens. I\u2019m assuming it is a
\nnon permanent problem that can enhance over time. As an alternative, the sub-agent
\nreported the variety of characters obtained and despatched and used
\ntiktoken<\/a> to approximate tokens, by dividing character rely by
\n4.<\/p>\n
Outcomes<\/h2>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Step<\/th>\n Information Entry Layer LoC<\/th>\n Largest file LoC<\/th>\n Complete Rust LoC<\/th>\n Enter tokens per change<\/th>\n Output tokens per change<\/th>\n Time per change (s)<\/th>\n<\/tr>\n<\/thead>\n
Baseline<\/td>\n 17,155<\/td>\n 17,155<\/td>\n 50,359<\/td>\n 159,564<\/td>\n 1,705<\/td>\n 342<\/td>\n<\/tr>\n
Step 1 (FirestoreClient)<\/td>\n 16,706<\/td>\n 16,706<\/td>\n 49,910<\/td>\n 155,205<\/td>\n 1,723<\/td>\n 530<\/td>\n<\/tr>\n
Step 2 (extract_doc_id, new_link)<\/td>\n 16,562<\/td>\n 16,562<\/td>\n 49,766<\/td>\n 159,227<\/td>\n 2,105<\/td>\n 574<\/td>\n<\/tr>\n
Step 3 (link-query helpers)<\/td>\n 16,567<\/td>\n 16,567<\/td>\n 49,771<\/td>\n 154,054<\/td>\n 2,105<\/td>\n 524<\/td>\n<\/tr>\n
Step 4 (FakeStore predicates)<\/td>\n 16,577<\/td>\n 16,577<\/td>\n 49,781<\/td>\n 154,146<\/td>\n 2,060<\/td>\n 654<\/td>\n<\/tr>\n
Step 5 (worth ctors)<\/td>\n 16,469<\/td>\n 16,469<\/td>\n 49,673<\/td>\n 171,251<\/td>\n 2,036<\/td>\n 1,353<\/td>\n<\/tr>\n
Step 6 (FieldsBuilder)<\/td>\n 16,469<\/td>\n 16,469<\/td>\n 49,673<\/td>\n 171,251<\/td>\n 2,036<\/td>\n 1,353<\/td>\n<\/tr>\n
Step 7 (queries.rs)<\/td>\n 16,474<\/td>\n 15,670<\/td>\n 49,678<\/td>\n 151,850<\/td>\n 1,800<\/td>\n 587<\/td>\n<\/tr>\n
Step 8 (traits.rs)<\/td>\n 16,508<\/td>\n 13,845<\/td>\n 49,712<\/td>\n 132,558<\/td>\n 1,723<\/td>\n 446<\/td>\n<\/tr>\n
Step 9 (traits\/ break up)<\/td>\n 16,508<\/td>\n 13,845<\/td>\n 49,712<\/td>\n 132,558<\/td>\n 1,723<\/td>\n 446<\/td>\n<\/tr>\n
Step 10 (codec.rs)<\/td>\n 16,521<\/td>\n 12,846<\/td>\n 49,725<\/td>\n 131,871<\/td>\n 1,750<\/td>\n 540<\/td>\n<\/tr>\n
Step 11 (fake_store.rs)<\/td>\n 16,535<\/td>\n 11,122<\/td>\n 49,739<\/td>\n 133,016<\/td>\n 2,460<\/td>\n 600<\/td>\n<\/tr>\n
Step 12 (retailer\/ break up)<\/td>\n 16,550<\/td>\n 9,269<\/td>\n 49,754<\/td>\n 104,080<\/td>\n 2,050<\/td>\n 490<\/td>\n<\/tr>\n
Step 13 (co-locate assessments)<\/td>\n 16,550<\/td>\n 9,269<\/td>\n 49,754<\/td>\n 104,080<\/td>\n 2,050<\/td>\n 490<\/td>\n<\/tr>\n
Step 14 (full fake_store.rs)<\/td>\n 16,553<\/td>\n 7,225<\/td>\n 49,757<\/td>\n 107,205<\/td>\n 2,453<\/td>\n 523<\/td>\n<\/tr>\n
Step 15 (retailer\/ break up)<\/td>\n 16,608<\/td>\n 3,695<\/td>\n 49,812<\/td>\n 27,360<\/td>\n 2,113<\/td>\n 454<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
The attention-grabbing metrics listed here are the full strains of code within the knowledge
\nentry layer, the full strains of code within the largest single file<\/em> in
\nthe information entry layer and the enter tokens consumed whereas producing
\nthe change.<\/p>\n
<\/p>\n
This chart exhibits 4 issues. The primary level is the baseline, step 0,
\nafter which the identical metrics are repeated after<\/em> every refactoring step
\nhas been utilized.<\/p>\n
\n
The entire strains of code within the knowledge entry layer as a
\ncomplete. Initially, that is simply the only file I began with. This
\nturns into many recordsdata as refactorings are utilized. By the tip there
\nare 19 Rust recordsdata.<\/li>\n
The strains of code within the single largest file within the knowledge entry
\nlayer. This began because the entirety of the information layer within the single
\npreliminary file. By the tip, the only largest file is a take a look at
\nlibrary. Additional refactoring passes may apply the identical strategy
\nto this.<\/li>\n
The entire enter tokens consumed by the sub-agent whereas making use of the
\nconsultant change.<\/li>\n
The entire output tokens produced by the sub-agent whereas making use of
\nthe consultant change.<\/li>\n<\/ol>\n
Refactoring reduces token consumption<\/h2>\n
The outcomes are clear. Enter tokens keep pretty flat till the biggest
\nfile begins to fall, after which they drop earlier than, within the phrases of
\nClaude, falling off a cliff.<\/p>\n
Between the bottom line and the ultimate refactoring, enter tokens for the
\nidentical activity diminished from 159,564<\/strong> to 27,360<\/strong>. A saving of
\n132,204<\/strong> tokens, or 83%<\/strong>. And that saving is just not a one-off. Each single
\nchange that touches the information entry layer from this level ahead now
\nprices considerably much less.<\/p>\n
How a lot of a saving? Assuming Sonnet 5 pricing on the time of writing
\nof $3\/MTok, 39.7 cents. Not quite a bit. Does it multiply? How will this
\nplay out throughout debugging? Extra sophisticated options? That is
\nrefactoring just one portion of the code base, can the entire code base
\nbe aggressively refactored to seek out financial savings in every single place? How a lot would
\nthese refactorings value?<\/em><\/p>\n
This saving is as a result of the agent has to learn much less code. However it isn’t
\nas a result of there may be much less code to learn. The general code within the knowledge
\nentry layer as an entire has stayed pretty fixed. Due to this fact to be
\nin a position to financial institution this saving, the agent should be capable to efficiently
\ndetermine the smallest subset of recordsdata essential to learn. The outcomes
\nmake it seem this was taking place. Studying the Claude Code considering
\noutput and file learn summaries because the change was being utilized additionally
\nsignifies the sub-agent was efficiently studying smaller and smaller
\nsections of code every time.<\/p>\n
In different phrases, randomly chopping the file into smaller recordsdata is
\nunlikely to assist as a lot: even when every file have been smaller, the agent
\ncan be compelled to learn via many recordsdata in search of the related
\ncode. Whereas the step with the most important impact occurs on the finish, the
\nearlier steps have been refactorings to arrange this saving. This was not
\ndeliberate. It was merely a results of how refactoring sometimes proceeds:
\nnative file adjustments to extract duplication, earlier than breaking down into
\nsmaller recordsdata as soon as a repeating core emerges.<\/p>\n
The refactoring didn’t make the consultant change smaller. The
\nvariety of tokens produced when writing code was largely unaffected:
\nthe output tokens don’t transfer very a lot. These tokens are 5 instances
\nthe value of the enter tokens. However, there are quite a bit much less of them. Are
\nthere refactorings that may very well be utilized to scale back output token
\nmanufacturing? I would like a extra advanced pattern change to discover these
\nquestions. The noise of the non-deterministic code technology course of
\nis hiding any variance brought on by adjustments within the factoring of the code.<\/p>\n
Notes on the method<\/h2>\n
Claude was not good at refactoring. If you happen to learn the immediate and the
\nrefactoring steps under, it\u2019s clear that the refactorings produced
\nhave been instantly in response to the immediate. Claude is unable to have a look at
\ncode, take a look at refactorings typically and work out that are appropriate
\nto use: a human must actively information it. This marries with wider
\nexpertise on this app. The event harness consists of an express
\nrefactoring step. That refactoring step didn’t immediate Claude into
\nenhancing this file. Extra anecdotally, Claude.ai was higher than
\nClaude Code. I used each interfaces to create the refactoring
\nplan. Claude Code noticed extract operate as the primary
\nstep. Claude.ai went additional and noticed a whole consumer class to be
\nextracted.<\/p>\n
It was additionally unhealthy at making use of them. The mechanical act of refactoring
\nwas carried out by writing Python scripts utilizing grep and sed. These
\nscripts steadily acquired confused by indentation. Oh, the irony. In
\naddition, the only most beneficial refactoring was missed within the first
\ngo, and needed to be re-applied as a follow-up step. This is the reason the
\nvariety of steps within the determine don\u2019t match the refactoring steps within the
\nappendix.<\/p>\n
It took about eight hours to finish your entire experiment. This was
\nlargely unattended. The one intervention was after six hours 40
\nminutes when it appeared to have completed, however had skipped that step
\nand wanted to be redirected. This experiment was operating on gradual
\nresort WiFi. I questioned if that contributed to time taken. However on
\ndeeper evaluation of the code base, the cargo non permanent construct cache had
\nturn out to be very massive. Check execution was struggling, considerably.<\/p>\n
Additional work and broader implications<\/h2>\n
Sadly, it didn\u2019t happen to me to carry out a rely of the tokens
\nrequired to create and execute the refactoring plan till it was
\nalready full. I\u2019ve checked out my combination consumption throughout the
\ntime window the place I used to be doing this work, together with designing and
\noperating the experiment. I can\u2019t say what number of tokens have been required to
\ncarry out the refactoring. The higher sure is 5 million,
\nnevertheless. This consists of creating the refactoring plan twice, the work
\nto design the experiment together with the consultant change, and
\nvaried different duties. Future work ought to embrace a extra correct rely
\nof tokens consumed to refactor.<\/p>\n
This is only one experiment, on a big utility that’s
\nnonetheless greenfield and constructed and maintained by a single developer. However,
\nI consider it is a probably attention-grabbing first step. This effort
\nexhibits the worth, in money and time of refactoring. In addition to
\nmeasuring how costly refactoring is. It could be attention-grabbing to
\ntake a look at extra advanced adjustments, at wider refactoring, refactoring
\nrepeatedly, and even the relative worth of various refactoring
\napproaches.<\/p>\n
That is only the start.<\/p>\n
Appendices<\/h2>\n
Be aware: These appendices embrace the prompts that I used, and the
\noutput that was returned. The one modifying utilized has been to take away
\nthe precise code adjustments to be made. These are included with out
\nmodifying to point out how the brokers have been directed. There aren’t any hidden
\ntips. As such, there may be some language in right here that is likely to be
\ncomplicated. The error is within the authentic.<\/em><\/p>\n
\n
The consultant change<\/summary>\n
That is the recorded immediate that was fed to every sub-agent, there was
\nno additional context equipped apart from the code base and accompanying
\nstructure documentation. Each sub-agent was beginning with precisely
\nthe identical info.<\/p>\n
\n
You might be working within the Rust mission at ~\/dev\/your-project-name<\/code>.<\/p>\n
Add a brand new ItemWatchStore<\/code> public async trait to the Firestore layer, following present patterns precisely. The trait will need to have three strategies:<\/p>\n
\nasync fn watch_item(&self, item_id: &str, user_id: &str) -> Outcome<()><\/code><\/li>\n async fn unwatch_item(&self, item_id: &str, user_id: &str) -> Outcome<()><\/code><\/li>\n async fn watched_items_for_user(&self, user_id: &str) -> Outcome><\/vec><\/code><\/li>\n<\/ul>\nWatches are saved in a item_watches<\/code> Firestore assortment. Every doc has fields: itemId<\/code> (string), userId<\/code> (string), createdAt<\/code> (timestamp). There isn’t any Rust struct for a watch report \u2014 the strategies return Vec<\/string><\/code> (merchandise ids).<\/p>\n Implement the trait for each FakeStore<\/code> (utilizing an in-memory Vec<(String, String)><\/code> subject added to FakeStoreInner<\/code>) and FirestoreStore<\/code> (utilizing the identical HTTP patterns used for different retailer impls on this file).<\/p>\n On the very finish of your response<\/strong>, output precisely this JSON block (fill in actual values):<\/p>\n {\n \"files_read\": [\n {\"path\": \"src\/firestore.rs\", \"chars\": 123456},\n ...\n ],\n \"response_chars\": 7890\n}\n<\/code><\/pre>\nDo NOT commit the change. Cease after writing the code.<\/p>\n<\/blockquote>\n<\/details>\n \nRefactoring steps<\/summary>\nThat is the immediate that was used to create the refactoring plan.<\/p>\n \nFollowing the strict definition {that a} refactoring is a provably \ncorrectness preserving sequence of code edits, and utilizing Martin \nFowler\u2019s 2nd version of Refactoring because the supply, study \n@src\/firestore.rs. This can be a 17K LoC Rust file. No file needs to be \nthat lengthy. It’s nearly actually not utilizing an inner language to \nconstruct and handle queries. Produce and describe, however don\u2019t execute, a \nsequence of refactorings that will massively cut back the road rely \nof that file, with out altering the interface in any respect.<\/p>\n<\/blockquote>\n Following is the outline of the refactorings utilized, extracted \nfrom the plan constructed and adopted by Claude. The precise plan consists of \npredicted code adjustments. For every refactoring, the person steps to \nobserve have been listed. Every of these steps was individually testable, and \nwas individually examined. This can be a stricter refactoring than most \nhuman engineers would observe.<\/p>\n The steps listed right here don\u2019t line up instantly with the measured adjustments \nabove as Claude skipped essentially the most useful single refactoring \n(splitting out the shop into sub-files) on the primary go and needed to \nfull that afterwards as two extra steps.<\/p>\n Fowler ref:<\/strong> Extract Class<\/em> (7.5); Extract Operate<\/em> (6.1) for \nevery primitive<\/p>\n FirestoreStore<\/code> at the moment conflates two tasks:<\/p>\n \nArea question orchestration<\/strong> \u2014 which question to run, which paperwork \nto put in writing, parse outcomes into area sorts<\/li>\n Firestore HTTP transport<\/strong> \u2014 auth headers, URL development, JSON \nencoding\/decoding of Firestore wire sorts, \nretry-on-PRECONDITION_FAILED<\/li>\n<\/ul>\nFowler \u00a77.5 requires extracting a brand new class when you’ll be able to determine a \ncoherent subset of a category\u2019s knowledge and behavior. The transport \naccountability owns: consumer: reqwest::Consumer<\/code>, project_id: String<\/code>, \nMetadataAuth<\/code>, and documents_url()<\/code> \/ auth_header()<\/code>. Extract these \ninto a brand new FirestoreClient<\/code> struct.<\/p>\n Estimated financial savings: ~1,200 strains in FirestoreStore<\/code> impls; \nFirestoreClient<\/code> provides ~120 strains web.<\/strong><\/p>\n Step 2 \u2014 Extract Operate: extract_doc_id<\/code> and new_link<\/code> (Fowler \u00a76.1)<\/h4>\nFowler ref:<\/strong> Extract Operate<\/em> (6.1)<\/p>\n \n\nextract_doc_id<\/code><\/strong> \u2014 The expression \ndoc.title.rsplit('\/').subsequent()?.to_string()<\/code> seems verbatim on the \nbegin of all 20 parse_*_document<\/code> capabilities. Extract it.<\/p>\n<\/li>\n \nnew_link<\/code><\/strong> \u2014 Constructing a Hyperlink<\/code> struct with metadata: \nHashMap::new()<\/code> and provenance: None<\/code> and a recent UUID seems 62 \ninstances. Extract a manufacturing unit operate.<\/p>\n<\/li>\n<\/ul>\n Estimated financial savings: ~500 strains<\/strong> (62 \u00d7 ~10-line structs \u2192 62 \u00d7 \n~2-line calls; 20 parse capabilities every lose 1 line of boilerplate).<\/p>\n Fowler ref:<\/strong> Extract Operate<\/em> (6.1)<\/p>\n Two sub-patterns recur contained in the FirestoreStore<\/code> trait impls after operating a hyperlink question:<\/p>\n \n\nSample A \u2014 gather all hyperlink paperwork from question rows (~15 \nwebsites).<\/strong><\/p>\n<\/li>\n \nSample B \u2014 question hyperlinks and return precisely one goal ID, error if \nlacking (~8 websites):<\/strong><\/p>\n<\/li>\n<\/ul>\n Estimated financial savings: ~200 strains.<\/strong><\/p>\n Fowler ref:<\/strong> Extract Operate<\/em> (6.1)<\/p>\n Contained in the FakeStore impls, ~15 strategies repeat variations of \ninside.hyperlinks.iter()...<\/code>.<\/p>\n Extract two strategies on FakeStoreInner<\/code>. The 15 callsites then turn out to be \nsingle-line. Strategies that moreover filter by a second predicate \n(e.g. additionally checking to_kind<\/code>) chain .into_iter().filter(\u2026)<\/code> on the \nresults of the helper.<\/p>\n Estimated financial savings: ~120 strains.<\/strong><\/p>\n Step 5 \u2014 Change Inline Code with Operate Name \u00d7 4: Firestore worth constructors<\/h4>\nFowler ref:<\/strong> Change Inline Code with Operate Name<\/em> (8.5)<\/p>\n Add 4 non-public free capabilities (file-level, not strategies) earlier than the \ncodec block. Change all 128+ json!({\"stringValue\": \u2026})<\/code> \/ \njson!({\"timestampValue\": \u2026})<\/code> and so forth. inline expressions with calls to \nthese capabilities. Every multi-word json macro name turns into a single \nbrief name.<\/p>\n Estimated financial savings: ~80 strains (largely from multi-line json macros collapsing to one-liners).<\/strong><\/p>\n Fowler ref:<\/strong> Extract Class<\/em> (7.3)<\/p>\n The ~20 encoder capabilities all observe this form:<\/p>\n let mut fields = serde_json::Map::new();\nfields.insert(\"foo\".to_string(), str_val(&x.foo));\nfields.insert(\"bar\".to_string(), ts_val(x.bar));\njson!({\"title\": path, \"fields\": fields})\n<\/code><\/pre>\nExtract a small builder. Rewrite every encoder operate to make use of the \nbuilder. A ~40-line encoder shrinks to ~12 strains.<\/p>\n Estimated financial savings: ~500\u2013600 strains throughout the 20 encoder capabilities.<\/strong><\/p>\n Fowler ref:<\/strong> Transfer Operate<\/em> (8.1)<\/p>\n Convert src\/firestore.rs<\/code> to a module listing: rename to \nsrc\/firestore\/mod.rs<\/code>. Then create src\/firestore\/queries.rs<\/code> and \ntransfer all 32 LinkQuery<\/code> constants and the \nLinkQuery<\/code>\/EqFilter<\/code>\/EqValue<\/code>\/Ordering<\/code>\/Route<\/code> kind \ndefinitions into it. Add pub(tremendous) use queries::*;<\/code> in mod.rs<\/code>.<\/p>\n No behaviour adjustments; all callsites already reference names that have been \nin scope by way of the flat file.<\/p>\n Reduces mod.rs<\/code> by ~800 strains.<\/strong><\/p>\n Fowler ref:<\/strong> Transfer Operate<\/em> (8.1)<\/p>\n Transfer all 17 pub trait<\/code> definitions (and their related error sorts) \nto src\/firestore\/traits.rs<\/code>. Re-export them from mod.rs<\/code> with pub \nuse traits::*;<\/code>.<\/p>\n Reduces mod.rs<\/code> by ~1,900 strains. Produces a ~1,900-line traits.rs<\/code> \nthat wants additional decomposition.<\/strong><\/p>\n Step 9 \u2014 Transfer Operate: break up traits.rs<\/code> right into a traits\/<\/code> module listing<\/h4>\nFowler ref:<\/strong> Transfer Operate<\/em> (8.1)<\/p>\n Convert src\/firestore\/traits.rs<\/code> to a module listing by grouping the 17 traits into 4 domain-aligned recordsdata:<\/p>\n\n\n\n\n\n\n\n\nFile<\/th>\n Traits<\/th>\n Approx strains<\/th>\n<\/tr>\n<\/thead>\n traits\/planning.rs<\/code><\/td>\n ConcentrationStore<\/code>, GoalStore<\/code>, ItemStore<\/code>, NoteStore<\/code>, PursuitStore<\/code>, FocusPassStore<\/code><\/td>\n ~650<\/td>\n<\/tr>\n traits\/content material.rs<\/code><\/td>\n CaptureStore<\/code>, TagStore<\/code>, UrlReferenceStore<\/code>, DocumentStore<\/code>, PaperStore<\/code><\/td>\n ~550<\/td>\n<\/tr>\n traits\/individuals.rs<\/code><\/td>\n ThoughtworkerStore<\/code>, ExternalContactStore<\/code>, CompanyStore<\/code><\/td>\n ~300<\/td>\n<\/tr>\n traits\/system.rs<\/code><\/td>\n SessionState<\/code>, LinkStore<\/code>, SuggestionStore<\/code>, SuggestionVetoStore<\/code>, OAuthTokenStore<\/code>, MigrationLedger<\/code>, EmbeddingStore<\/code>, RuntimeConfigStore<\/code>, SalesforceSyncStateStore<\/code><\/td>\n ~400<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\ntraits\/mod.rs<\/code> turns into a pure re-export file (~20 strains). Related \nerror sorts (FocusPassError<\/code>, SuggestionDecisionError<\/code>, and so forth.) transfer \nwith the trait that produces them.<\/p>\n No trait definition adjustments, no callsite adjustments \u2014 solely \nrelocation. Every ensuing file is 300\u2013650 strains.<\/strong><\/p>\n Fowler ref:<\/strong> Transfer Operate<\/em> (8.1)<\/p>\n Transfer all doc encoder\/decoder capabilities (*_document<\/code>, \nparse_*_document<\/code>, kind_str<\/code>, parse_kind<\/code>, parse_capture_source<\/code>, \nparse_outcome<\/code>, and so forth.) plus FieldsBuilder<\/code> and the worth constructors \nfrom Steps 5 and 6 into src\/firestore\/codec.rs<\/code>. Make them \npub(tremendous)<\/code>.<\/p>\n After Step 6 this module can be ~400\u2013500 strains relatively than ~1,200.<\/p>\n Reduces mod.rs<\/code> by ~500 strains (post-Step-6).<\/strong><\/p>\n Fowler ref:<\/strong> Transfer Operate<\/em> (8.1)<\/p>\n Transfer FakeStore<\/code>, FakeStoreInner<\/code>, and all 18 trait impl blocks for \nFakeStore<\/code> into src\/firestore\/fake_store.rs<\/code>. Re-export FakeStore<\/code> \nfrom mod.rs<\/code> with pub use fake_store::FakeStore;<\/code>.<\/p>\n FakeStoreInner<\/code> and helper strategies keep non-public to the module.<\/p>\n Reduces mod.rs<\/code> by ~4,700 strains.<\/strong><\/p>\n Step 12 \u2014 Transfer Operate: break up FirestoreStore<\/code> impls into per-trait recordsdata beneath src\/firestore\/retailer\/<\/code><\/h4>\nFowler ref:<\/strong> Transfer Operate<\/em> (8.1)<\/p>\n Create src\/firestore\/retailer\/mod.rs<\/code> with FirestoreStore<\/code> struct \ndefinition, impl FirestoreStore<\/code> (constructor + FirestoreClient<\/code> \nfrom Step 1), and MetadataAuth<\/code>.<\/p>\n Then create one file per logical area grouping.<\/p>\n Every file accommodates solely use tremendous::*;<\/code> (or express imports) and the \ntrait impl block(s). No kind definitions, no helpers. Helpers utilized by \na number of impl blocks keep in retailer\/mod.rs<\/code>.<\/p>\n Reduces what can be a ~10,000-line file into ten recordsdata of 120\u2013650 \nstrains every. mod.rs<\/code> turns into a ~100-line re-export manifest.<\/strong><\/p>\n Step 13 \u2014 Transfer Operate: co-locate assessments with their modules<\/h4>\nFowler ref:<\/strong> Transfer Operate<\/em> (8.1)<\/p>\n The prevailing #[cfg(test)]<\/code> modules take a look at particular area areas and \nbelong with the modules created in Step 12 relatively than in a single \nassessments.rs<\/code>.Every take a look at module strikes inside a #[cfg(test)] mod assessments { \u2026 \n}<\/code> block on the backside of the goal file, with use tremendous::*;<\/code> to \nentry the module\u2019s internals. No take a look at is modified, solely relocated.<\/p>\n Any shared take a look at fixtures (FakeStore::new<\/code>, helper builders) which are \nalready in fake_store.rs<\/code> are accessible by way of the prevailing use \ntremendous::fake_store::FakeStore<\/code> import chain.<\/p>\n Reduces mod.rs<\/code> by ~2,000 strains; every goal file beneficial properties 200\u2013700 \nstrains of assessments which are instantly adjoining to the code they train.<\/strong><\/p>\n<\/details>\n<\/div>\n\n","protected":false},"excerpt":{"rendered":" As a part of attending to grips with the brand new world of agentic engineering, I constructed an utility to help my work. It\u2019s a classy app: high-quality internet UI with dynamic refresh and look-up, modals and auto-save, integrations to exterior methods, machine studying and textual content evaluation, background jobs, and a correct atmosphere setup […]<\/p>\n","protected":false},"author":2,"featured_media":17293,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[56],"tags":[9994,9993,7913],"class_list":["post-17291","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-software","tag-benefit","tag-economic","tag-refactoring"],"_links":{"self":[{"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=\/wp\/v2\/posts\/17291","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=17291"}],"version-history":[{"count":1,"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=\/wp\/v2\/posts\/17291\/revisions"}],"predecessor-version":[{"id":17292,"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=\/wp\/v2\/posts\/17291\/revisions\/17292"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=\/wp\/v2\/media\/17293"}],"wp:attachment":[{"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=17291"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=17291"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/techtrendfeed.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=17291"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}