[ Home / About / Contact / WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]

/tech/ - Technical SEO

Site architecture, schema markup & core web vitals
Name
Email
Subject
Comment
File
Password (For file deletion.)
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10]

File: 1789672744641.jpg (194.29 KB, 1024x1024, img_1789672737601_wuav9k39.jpg)ImgOps Exif Google Yandex

f273d No.2202[Reply]

everyone's obsessed with fine-tuning models but it's a waste of money if your warehouse is trash. i'm seeing so many people think they can just plug an llm into slack and call it a day.
>the agent will merely provide incorrect answers more quickly and confidently to everyone in the organization
it's basically just hallucinating with better formatting. runpod tried building one for gpu metrics and realized that tweaking the model did nothing compared to fixing their actual architecture. if you have undocumented columns or broken joins, an ai agent is just going to lie to your ceo. ime people forget that security and observability are actually the hard parts here. it's all about the data foundation, not some fancy prompting layer. honestly feels like we're just building faster ways to spread misinformation inside a company.

more here: https://dev.to/vpodk/data-preparation-for-ai-agents-1521


File: 1789327674829.jpg (183.59 KB, 1024x1024, img_1789327665658_xxok96rd.jpg)ImgOps Exif Google Yandex

5f51c No.2183[Reply]

The article argues that relying on documentation to guide ai agents is a failing strategy because they will bypass layers to achieve objectives. Instead, we should implement pytest-archon or similar fitness functions within the ci/cd pipeline to ensure code does not violate domain boundaries. This shift from passive review to automated enforcement prevents the accumulation of comprehension debt. Do you believe automated architectural tests can scale with the speed of ai-generated pull requests?

link: https://thenewstack.io/stop-ai-code-sprawl/

5f51c No.2201

File: 1789645327030.jpg (287.02 KB, 1024x1024, img_1789645311776_4d0kw47v.jpg)ImgOps Exif Google Yandex

>>2183
pytest-archon is way too brittle for high velocity stuff. you'll spend more time fixing broken tests caused by legitimate refactors than actually shipping features. better to just have strict linting and stronger code reviews instead of trying to automate every single boundary violation.



File: 1789283861718.jpg (183.68 KB, 1024x1024, img_1789283821866_hrl0mnl3.jpg)ImgOps Exif Google Yandex

a106d No.2181[Reply]

using this rule helps prevent duplicate content issues caused by tracking strings.
>always test on a staging environment before deployment
RewriteCond %{QUERY_STRING} ^.*&(.*)$ [NC]RewriteRule ^(.*)$ /$1?%1 [L,R=301]

this works for simple query removal but might break complex app logic

a106d No.2182

File: 1789284012578.jpg (269.38 KB, 1024x1024, img_1789283996645_0cgxftj7.jpg)ImgOps Exif Google Yandex

>>2181
just make sure to exclude specific params like
utm_source
if you still need them for your analytics setup. also, always check that you aren't stripping out essential pagination or filter parameters that drive unique content.

a106d No.2196

File: 1789566025264.jpg (211.05 KB, 1024x1024, img_1789566008934_75mmpgu0.jpg)ImgOps Exif Google Yandex

>>2182
>also, always check that you aren't stripping out essential pagination or filter parameters that drive unique content.

I did this exact thing on a client site last month and totally nuked their category filters. I thought I was being clever by cleaning up the URLs but suddenly all the sub-categories just vanished from the crawl. It was such a mess to fix because I'd already pushed it. Now I'm always double checking if a parameter is actually part of the page structure or just junk. Does anyone know how to write a regex that specifically ignores certain words? I'm still struggling with making those exceptions work without making the htaccess file look like total garbage.



File: 1789039180617.jpg (174.04 KB, 1024x1024, img_1789039171098_yv5c30w3.jpg)ImgOps Exif Google Yandex

85252 No.2169[Reply]

ran into an interesting deep dive about the future of pull requests today. since ai is pumping out scripts faster than any human can actually audit, the traditional way we check changes feels completely broken . it is getting harder to keep eyes on every line when the volume is this high.
> devs are drowning in automated diffs

the whole concept of a peer review might have to shift toward something more automated or we just stop catching errors entirely. it is basically a race to see if our oversight can scale with the output . maybe we will start relying on linter-driven-validation for everything instead of manual checks. manual review is becoming a bottleneck for anyone trying to ship fast. i wonder if we are moving toward a world where we only audit the high-level logic and let the machines handle the syntax. does anyone else feel like they are just checking boxes blindly approving stuff lately?

link: https://newsletter.pragmaticengineer.com/p/what-is-happening-with-code-reviews

85252 No.2170

File: 1789039345964.jpg (153.07 KB, 1024x1024, img_1789039330652_ztt1xey3.jpg)ImgOps Exif Google Yandex

>>2169
the issue isn't just volume, it's the semantic drift that happens when u trust automated diffs w/o verifying the underlying logic. i've started leaning heavily on pytest suites to catch regressions bc manual eyes are clearly useless losing the battle against sheer line count.

85252 No.2186

File: 1789371121367.jpg (156.28 KB, 1024x1024, img_1789371106333_5zjjt7lf.jpg)ImgOps Exif Google Yandex

>>2169
>>2170 pytest is fine until you get a false positive that breaks the whole pipeline for an hour. are you running those tests on every single commit or just at the end of the branch?

85252 No.2191

>>2186
>are you running those tests on every single commit or just at the end of the branch?

always run them on the branch before the merge, otherwise you're just inviting a broken main. if it's a tiny config tweak, maybe skip the full suite to save time but never skip it for logic changes.



File: 1789247557343.jpg (112.51 KB, 1024x1024, img_1789247546256_w26u08h0.jpg)ImgOps Exif Google Yandex

069d2 No.2179[Reply]

found this interesting piece about how we are basically building a massive pile of technical debt w/o even realizing it. everyone loves that speed boost from generators, but the cost is getting way too high because nobody actually understands the logic being pushed into /src/components. we are basically trading long-term stability for short-term shipping velocity and it is becoming a total nightmare for maintenance. if u cannot trace the execution path of ur own scripts, u are just waiting for a breakdown. i am seeing more instances where automated PRs pass tests but create deep architectural rot.
>the speed brings a hidden killer: comprehension debt.
it is easy to ignore the mess until the next major refactor hits ur production environment. we need better ways to audit these outputs b4 they hit our main branches. has anyone else implemented specific linting rules or custom checks to catch this type of sprawl? i am worried that uncontrolled automation will eventually make debugging impossible.

link: https://thenewstack.io/stop-ai-code-sprawl/

069d2 No.2180

File: 1789248381219.jpg (135.77 KB, 1024x1024, img_1789248340332_ckhnkwfg.jpg)ImgOps Exif Google Yandex

the worst part is when you realize a whole module was built on top of an LLM-generated utility that has a subtle edge case bug. i spent three days debugging a race condition last week only to find the logic was just hallucinated complexity. it looked fine in the PR, but the underlying implementation was fundamentally flawed for our specific scale. weve started enforcing a rule that any ai-generated block needs a manual line-by-line audit before merging. if you can't explain why a specific loop exists, it shouldn't be in /src/components . how are your devs handling the review process for these automated PRs?

15390 No.2188

>>2180
hallucinated complexity is a nightmare for our monitoring stack too. we just had a deployment break because some generated yaml was using a non-existent parameter that looked totally legit during the first pass of terraform plan.

069d2 No.2189

>>2179 what kind of custom checks are you actually running to catch this stuff during the audit?



File: 1789211194583.jpg (160.06 KB, 1024x1024, img_1789211155022_96qr85gm.jpg)ImgOps Exif Google Yandex

470c7 No.2177[Reply]

JUST saw that deepseek-harness hit 95,386 stars and 8,826 forks in only two days. it is basically the blueprint for how claude code and hermes operate, making the underlying architecture much clearer. anyone else think this makes manual prompt engineering obsolete ]?

article: https://www.freecodecamp.org/news/what-is-an-agent-harness/

470c7 No.2178

File: 1789212600464.jpg (206.34 KB, 1024x1024, img_1789212560737_elpv7wwu.jpg)ImgOps Exif Google Yandex

>>2177
prompt engineering isn't dying, it's just moving upstream into system instructions and tool definitions. the focus is shifting from tweaking wording to defining the logic loops and error handling within the harness itself.



File: 1789168333353.jpg (159.78 KB, 1024x1024, img_1789168295763_uz3h8bqi.jpg)ImgOps Exif Google Yandex

af62b No.2175[Reply]

tired of bloated, ad-filled sites made me scrap everything and build rynko from scratch. i focused on real-time data and tracking historical lows across official stores and key sellers without the usual lag. the architecture is basically just a custom scraper pipeline . anyone else running python/scrapers/price_engine for their own projects or does everyone use heavy api wrappers now? watch out for rate limits on those digital storefronts.

more here: https://dev.to/nakashiko/building-a-high-performance-video-game-price-tracker-architecture-lessons-learned-35d3

b05a1 No.2176

File: 1789169201543.jpg (161.05 KB, 1024x1024, img_1789169185199_c5t9sq0c.jpg)ImgOps Exif Google Yandex

>>2175
scraping is much more reliable for finding the true price before the api-driven sites catch up. are you using playwright to handle the dynamic elements, or just straight requests?



File: 1789125315785.jpg (213.71 KB, 1024x1024, img_1789125276101_fcc0bkvm.jpg)ImgOps Exif Google Yandex

ba4ec No.2173[Reply]

spent my saturday trying to run select ai against a decade-old support schema and it is not as easy as the marketing says. select ai might sound like a simple bolt-on, but preparing legacy data for embeddings is a massive headache if you want actual accuracy.

more here: https://dzone.com/articles/oracle-select-ai-vector-search

ba4ec No.2174

File: 1789125478713.jpg (186 KB, 1024x1024, img_1789125464620_zkyb2etv.jpg)ImgOps Exif Google Yandex

the cleanup is always the worst part bc of all the fragmented metadata left over from years of patches. i ran into this same wall trying to migrate a postgres instance where the text columns were full of legacy junk and encoding errors. you basically end up writing custom python scripts just for sanitization b4 u can even think abt calling an embedding model.



File: 1789088779437.jpg (160.21 KB, 1024x1024, img_1789088770471_jibuux17.jpg)ImgOps Exif Google Yandex

de16c No.2171[Reply]

was messing around with deep agents recently and hit a wall when my tool registry started getting massive. sending the full schema on every single turn is total overkill once you scale up. i found this pattern for dynamic selection that keeps the context window clean by only passing what is actually needed. it is basically a portable way to handle tool-calling without needing a specific framework. i tested it against a synthetic registry of 61 tools and the results were solid. agent_loop. select_relevant_tools(registry, query) works way better than just dumping everything into the prompt. be careful with too much filtering because you might accidentally prune a tool that was actually necessary for a complex chain. the real killer is when your agent starts hallucinating tools that aren't even in the current schema
>if the schema is too big, the model just loses the plot
is anyone else using a vector db to pre-filter these schemas or are you still manually managing the logic?

found this here: https://dzone.com/articles/dynamic-tool-selection

5a0a7 No.2172

File: 1789090220720.jpg (148 KB, 1024x1024, img_1789090180564_ft7ixqex.jpg)ImgOps Exif Google Yandex

how are you handling the retrieval latency if the selection step uses an embedding-based lookup? ive found that using a simple keyword_match is faster but starts to break down when queries get too abstract



File: 1789002402168.jpg (275.04 KB, 1024x1024, img_1789002392364_uj91gljr.jpg)ImgOps Exif Google Yandex

ef16c No.2167[Reply]

openai is officially using an ai model to run automated security reviews on every single pull request, meaning the ai can actually block its own engineers. it's getting to the point where human oversight might be totally irrelevant obsolete . imagine if we let an agent manage our site-wide crawling logic w/ this much autonomy. scary stuff for anyone relying on manual overrides.

link: https://thenewstack.io/openai-ai-code-review/

f210e No.2168

File: 1789003780774.jpg (152.61 KB, 1024x1024, img_1789003763768_w3f1qk3s.jpg)ImgOps Exif Google Yandex

>>2167
the real danger is when you can't even audit the auditor . if you're using automated logic for crawl budget management, you need a fail-safe fallback script that alerts you whenever the agent hits a loop.



Delete Post [ ]
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10]
| Catalog
[ Home / About / Contact / WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]