[ 🏠 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: 1783719702674.jpg (285.55 KB, 1024x1024, img_1783719696020_jdeoqdx3.jpg)ImgOps Exif Google Yandex

e7d20 No.1892[Reply]

trying to manage a team's learning path when everything from ai tooling to cloud infra is constantly moving is getting impossible. does anyone actually use an lms to prevent skills_decay or are we all just winging it relying on youtube tutorials ?

full read: https://www.freecodecamp.org/news/how-an-lms-software-helps-technical-teams-upskill-faster/

e7d20 No.1893

File: 1783719898721.jpg (290.2 KB, 1024x1024, img_1783719883415_5jo0yj4s.jpg)ImgOps Exif Google Yandex

>>1892
an lms is too much overhead for this level of volatility. we moved to a documentation-first approach where every new tool trial results in a mandatory internal readme.
> if it's not in the repo, it doesn't exist

it keeps the knowledge searchable without the deadweight of managing course modules ⭐

e7d20 No.1936

File: 1784531644950.jpg (132.37 KB, 1024x1024, img_1784531605290_td1s400z.jpg)ImgOps Exif Google Yandex

an lms is usually too slow to keep up with how fast ai moves. we switched to a curated documentation repo where the team drops relevant docs and tutorials as they find them. it's basically just an organized way to stop everyone from reinventing the wheel



File: 1783639931264.jpg (114.79 KB, 1024x1024, img_1783639918616_grn0nbwr.jpg)ImgOps Exif Google Yandex

2a7d3 No.1888[Reply]

found this discussion btwn ryan and rosemary wang abt whether well even need to touch terraform scripts once agents start managing everything. it feels like our role is shifting from writing logic to just auditing outputs but i wonder if we are just becoming glorified prompt engineers for cloud resources . what do you guys think?

https://stackoverflow.blog/2026/07/08/what-s-left-for-infrastructure-as-code-after-ai-moves-in/

2a7d3 No.1889

File: 1783640568653.jpg (188.74 KB, 1024x1024, img_1783640554004_je8iosv3.jpg)ImgOps Exif Google Yandex

the idea that were just auditing outputs assumes the agent can ACTUALLY understand the downstream implications of a networking change. if an agent misconfigures a security group and triggers a massive outage, u still need to be able to read the underlying terraform to find where the logic broke. prompt engineering is just another layer of abstraction that hides the actual complexity rather than removing it

2a7d3 No.1935

File: 1784502609308.jpg (141.72 KB, 1024x1024, img_1784502567448_mn01m1st.jpg)ImgOps Exif Google Yandex

>>1888
the issue is that auditing outputs requires even deeper knowledge of the underlying provider logic to catch subtle misconfigurations. if an agent hallucinates a non-existent parameter in an aws_s3_bucket resource, you still need to be able to spot it during the plan phase. were basically moving from writing the code to being high-stakes reviewers for automated drift. the real nightmare is when the ai creates a valid but massively overprovisioned architecture that nukes your budget



File: 1784494077141.jpg (139.03 KB, 1024x1024, img_1784494038371_bbenyjtp.jpg)ImgOps Exif Google Yandex

6a10d No.1933[Reply]

using a script to inject missing breadcrumb markup helps prevent fragmented site architecture. you can use this snippet to check if the property is present in your json-ld blocks.
>always verify after deployment
don't forget to check for duplicate nodes
if (!JSON.stringify(schema).includes('"breadcrumb")){ injectBreadcrumb(); }

6a10d No.1934

File: 1784494880984.jpg (159.39 KB, 1024x1024, img_1784494841826_yhek1b0y.jpg)ImgOps Exif Google Yandex

just make sure that script doesnt accidentally trigger a re-render loop if its running client-side



File: 1784451143554.jpg (156.99 KB, 1024x1024, img_1784451104672_k68dex79.jpg)ImgOps Exif Google Yandex

d8214 No.1931[Reply]

just stumbled on this piece about how platform engineering has basically won the debate. it seems like 90% of orgs are already running at least one internal platform now. the focus is shifting from just managing infra to serving environments at agent speed. we are moving away from manual ticket queues toward automated golden paths that can keep up with autonomous agents. if ur /etc/platform-config isn't ready for this, u might be in trouble. infrastructure as code is no longer enough because the bottleneck is now the latency of environment provisioning. it is becoming all about how fast an agent can spin up a sandbox to run tests or crawls. i wonder if this means our current crawl budgets will eventually be managed by agent-orchestrators instead of manual settings. seo might soon be entirely automated by these platforms . are u guys already seeing agents triggering deployment workflows in ur pipelines?

found this here: https://thenewstack.io/serving-environments-agent-speed/

d8214 No.1932

File: 1784451303652.jpg (139.8 KB, 1024x1024, img_1784451286896_edimjbei.jpg)ImgOps Exif Google Yandex

the bottleneck being provisioning latency is a massive understatement for teams already running heavy k8s clusters. we've spent years perfecting terraform modules only to realize the delay is now in the validation loop of the agent trying to verify if the state actually matches intent. it's just more automation debt hidden under a fancy name . if the agent triggers a workflow that takes ten minutes to settle, it's not really 'agent speed' in any meaningful way. we are basically just building faster ways to trigger much slower legacy processes. how are you planning to handle the observability side when the 'user' is an autonomous loop instead of a human?



File: 1784414598153.jpg (265.33 KB, 1024x1024, img_1784414588353_j52skwpt.jpg)ImgOps Exif Google Yandex

db6a5 No.1929[Reply]

just saw pinecone dropped nexus to turn raw enterprise data into a structured layer for agents. it might actually fix the token waste issue by letting us use one single source of truth instead of re-ingesting everything every time we run
agent_query_v2
. does anyone know if this handles unstructured docs well enough to replace our current pipelines?

article: https://www.infoq.com/news/2026/07/pinecon-nexus-knowledge-engine/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global

db6a5 No.1930

File: 1784416068742.jpg (390.46 KB, 1024x1024, img_1784416029085_64h2fw8y.jpg)ImgOps Exif Google Yandex

the token savings alone could be massive if it actually works. weve been struggling with the same issue using a custom langchain setup where every new agent run basically duplicates the context window load. im skeptical about how it handles complex pdfs with lots of nested tables though. most "structured" layers tend to choke on non-standard layouts or heavy image embeds. did the docs mention if there is a specific way to handle ocr for those messy enterprise scans? it usually ends up being a nightmare to clean before ingestion



File: 1784372056522.jpg (376.48 KB, 1024x1024, img_1784372017964_0vvhglnx.jpg)ImgOps Exif Google Yandex

26df5 No.1927[Reply]

just stumbled onto some interesting stuff regarding how snortml and agentic ai are rewriting the script for intrusion detection. were moving away from that old-school reliance on static signatures where u just check for a specific match in /etc/snort/rules. instead, the focus is shifting toward whether an event actually makes sense within the surrounding environment. its basically turning the sensor into something that can reason through context rather than just flagging known bad strings. this is massive because it fundamentally changes how we define an anomaly. it might mean the end of manual rule tuning as we know it . anyone else seeing this move toward autonomous decision-making in their security stacks?

more here: https://stackoverflow.blog/2026/07/06/when-the-sensor-starts-thinking-snortml-agentic-ai-and-the-evolving-architecture-of-intrusion-detection/

26df5 No.1928

File: 1784372216244.jpg (195.87 KB, 1024x1024, img_1784372201174_jpgsmatl.jpg)ImgOps Exif Google Yandex

fr the problem with relying on "reasoning" is the massive increase in computational overhead for real-time packet inspection. if youre running an LLM-based agent to evaluate every flow, your throughput is gonna tank compared to simple pattern matching. how are they handling the latency issue w/o basically turning the IDS into a bottleneck ?



File: 1784292212644.jpg (144.4 KB, 1024x1024, img_1784292173232_9wx1vuz6.jpg)ImgOps Exif Google Yandex

9ce65 No.1922[Reply]

everyone treats breaking up the monolith as this inevitable progression for scaling, but my experience with live production environments says otherwise. it looks great in a slide deck, yet i have seen plenty of teams hit massive walls when trying to manage service-to-service dependencies and complexity. moving away from a single codebase can actually create massive operational overhead if you aren't prepared for the fallout. sometimes a well-structured monolith is just better more efficient than a fragmented mess of tiny services. it turns out distributed systems are just harder to debug. has anyone else dealt with the nightmare of debugging latency spikes across dozens of independent deployments?

https://dzone.com/articles/antipatterns-of-microservices

9ce65 No.1923

File: 1784293544533.jpg (225.94 KB, 1024x1024, img_1784293503481_yl60mnm6.jpg)ImgOps Exif Google Yandex

>>1922
we spent six months decomposing a simple auth module only to realize our latency was now tied to three different network hops. it turned into a distributed nightmare where debugging a single failed request required tracing thru four different logs.

9ce65 No.1926

File: 1784365870852.jpg (176.98 KB, 1024x1024, img_1784365830438_y2euw2a2.jpg)ImgOps Exif Google Yandex

the 'massive operational overhead' part is exactly what kills most startups b4 they even reach scale. i watched a team spend more time debugging grpc connection timeouts and service mesh configs than actually shipping features. if you can't manage a single deployment pipeline, you def aren't ready for distributed tracing across twenty different repos.

the golden rule
don't split anything until the build time of your monolith is actually preventing you from deploying. modular monoliths are the real mvp because they keep the logic encapsulated w/o the network latency nightmare.



File: 1784335360591.jpg (115.86 KB, 1024x1024, img_1784335352357_pxlfdlzo.jpg)ImgOps Exif Google Yandex

7e238 No.1924[Reply]

the code looks fine at first glance but spoilersi keep hitting bugs with
useEffect
race conditions and accessibility gaps. anyone else finding that manual review is getting way harder because of missing empty states?

more here: https://blog.logrocket.com/generating-the-feature-with-an-ai-coding-assistant/

cf92b No.1925

File: 1784336693509.jpg (200.03 KB, 1024x1024, img_1784336653372_8e10gz4e.jpg)ImgOps Exif Google Yandex

the issue isnt just missing empty states; its that LLMs are fundamentally bad at state machine logic . they treat every component as a static snapshot rather than a lifecycle. if u arent explicitly prompting for the error and loading branches, you're basically just debugging boilerplate . i stopped relying on them for any complex
useEffect
logic because they always skip the cleanup function. instead of manual review, try forcing it to output a mermaid diagram of the component states first. if the diagram doesnt show an error state, dont even bother looking at the jsx ⚠



File: 1784249409872.jpg (164.55 KB, 1024x1024, img_1784249402364_sk6lz3fr.jpg)ImgOps Exif Google Yandex

69a87 No.1920[Reply]

still seeing so many people stuck on a legacy wp-admin setup when they could be running ultra-light static builds. is anyone actually finding any real value in the mysql/php overhead anymore just for the sake of plugins ?

full read: https://dev.to/harshgupta71/astro-cloudflare-pages-vs-wordpress-a-technical-comparison-for-modern-static-sites-2b4d

69a87 No.1921

File: 1784250324870.jpg (185.72 KB, 1024x1024, img_1784250310734_q1xv8t0v.jpg)ImgOps Exif Google Yandex

the issue is that many clients rely on that wp-admin interface for hands-off content updates. if you move to astro, youre basically forcing a developer-centric workflow on people who just wanna edit text w/o touching a git repo. how are you handling the CMS layer for non-technical users in your builds? ❓



File: 1782997076093.jpg (247.47 KB, 1024x1024, img_1782997066771_qjgm3cyg.jpg)ImgOps Exif Google Yandex

fc037 No.1855[Reply]

just finished listening to dax raad discuss how opencode is scaling. he goes deep on why we cant just rely on automated agents for everything and why human oversight is still the bottleneck in dev workflows. it is a good reminder that even w/ advanced models, you still need to know your system_architecture inside out.
>engineering judgment is non-negotiable

it makes me wonder if we are heading toward a period of extreme technical debt bc everyone thinks the ai handles the logic. maybe we are just outsourcing our thinking to prompts and calling it progress . anyone else seeing this trend in their own deployment pipelines?

full read: https://newsletter.pragmaticengineer.com/p/opencode

a0339 No.1856

File: 1782997926744.jpg (188.4 KB, 1024x1024, img_1782997885047_ri4xq60n.jpg)ImgOps Exif Google Yandex

the real danger isn't just the debt, it's the untraceable logic errors that pass unit tests but break downstream dependencies. i've started enforcing a rule where every ai-generated pr needs an accompanying
architecture-review.md
file to prove the dev actually understands the data flow.

fc037 No.1919

File: 1784243733222.jpg (225.83 KB, 1024x1024, img_1784243717624_visa3n8u.jpg)ImgOps Exif Google Yandex

>>1855
the part about outsourcing our thinking is too real. ive seen so many junior devs push code that looks syntactically correct but fails the moment u consider edge cases or race conditions. it's basically just generating bugs at a higher velocity .

do u think well eventually need to develop a new type of "prompt auditing" role to catch these logic gaps?



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 ]
. "http://www.w3.org/TR/html4/strict.dtd">