DEV Community: cenk

Everyone Started Using AI. But What About Standards?

cenk — Sun, 10 May 2026 16:12:26 +0000

Building an AI-Assisted Development Culture in a Small Team

When we first introduced Cursor, the team adopted it very fast. Faster than expected.

But reactions were not the same. Some people were excited and tried many tools. Some were careful. Some asked clearly: "Will this hurt my personal growth?" Some saw a threat, others saw an opportunity.

This variety was actually healthy. But it also showed one clear gap: we had a shared tool, but not a shared way to use it. We needed to close that gap.

This article explains how we built AI-assisted development practices and standards from zero in an engineering team with more than five people.

People first: adoption does not happen by one decision

The technical part of introducing AI tools was the easy part. The hard part was aligning people with different concerns.

The question "Will this tool make me unnecessary?" can stay in the room even if no one says it. We discussed it directly. Our answer was clear: AI does not replace ownership. It helps us write faster. Judgment, responsibility, and final approval still belong to humans.

Without this cultural base, standards do not stick. Rules are not adopted by force. They are adopted when people understand the reason behind them.

Two languages, one standard

Our team works with both .NET and Python. Two ecosystems, two syntax styles, two toolchains. But we use one team standard.

This was a conscious choice. Every developer keeps working in the language they know best. But deployment flow, logging format, code review expectations, and prompt approach are defined in a language-independent way.

The result is simple: a .NET developer can follow deployment in a Python service. Logs from Python are readable in a familiar format for .NET developers. Different languages, same engineering language.

AI tools made this stronger. Code generated with Cursor or similar tools is reviewed with the same standards, no matter which language is used.

RAG helps team knowledge scale

Documenting standards is one step. Helping people reach the right document at the right time is another step.

Here, RAG (Retrieval-Augmented Generation) helped us. Team standards, past decisions, architecture notes, and prompt library were indexed. Now a developer can get a direct answer instead of asking, "Which prompt do we use for deployment?"

There is an important side effect: institutional memory grows. A new team member can access a structured knowledge base during onboarding, not scattered documents. The answer to "Why do we do it this way?" is no longer only in one person’s head.

Tool diversity: problem or strength?

Excited team members did not stop at Cursor. They tested other tools, compared them, and discussed results.

Instead of forcing one tool, we used a different approach: tool choice can be personal, but output standards are shared.

You can generate code with any tool. But review process, code quality expectations, and documentation standards are the same. This helped us keep consistency without killing curiosity.

Prompt standards as team language

We stopped treating prompt writing as an individual trick. We made it a team practice.

We used three basic rules:

Context comes first. Instead of saying "write this," we say "write this in this system, with this constraint, for this goal." Explaining why improves output quality.

Define output format. Function, test, or comment. Expected format should be inside the prompt. Vague prompts create vague outputs.

Document and share prompts. Reusable prompts were added to our team library and made searchable through RAG. Experience accumulates, and every developer does not need to start from zero.

Deployment: repeatable process, not chaos

AI increased speed, and one side effect appeared: people also wanted faster production release. The reflex "it works, deploy now" can become dangerous.

To prevent this, we made staging mandatory. Development in production was fully blocked. Every change goes to staging first, is validated there, and then moves to production.

We also standardized deployment steps and prompt templates:

Deploy: Move the change to the environment
Promote: Approve move from staging to production
Status validate: Check system health after deployment

These steps work the same way for both .NET and Python services.

Design system and logging: visible consistency, invisible reliability

To make interfaces written by different developers look consistent, we adopted a design system. Colors, component behavior, and spacing are centrally defined. AI-generated UI code also follows this system.

On the invisible side, we have a logging standard. Every service logs critical actions and errors with the same format and detail level in both .NET and Python. When something fails in production, we no longer guess. We read consistent logs.

Together, these two standards give us a system that is consistent outside and observable inside.

Three short lessons

Tool adoption can happen naturally. Culture adoption must be built. Working with two languages is not a reason to relax standards. It is proof that standards are even more important. And making team knowledge accessible with RAG is one of the most practical ways to turn individual expertise into organizational intelligence.

Secure and High-Performance Static Website Architecture with WordPress Content

cenk — Sun, 04 Jan 2026 18:15:42 +0000

The starting point of this work was a simple but critical need: to build a website that is both secure and high-performance.
Over time, this goal evolved beyond making a site “faster” and led to questioning the architecture itself. WordPress was a powerful content production tool, but when it was also responsible for content delivery, it introduced unnecessary security and performance risks.
To address this, WordPress was deliberately limited to content production only, while all published content was delivered through a fully static website. This architectural decision resulted in significant gains on both the security and performance fronts.

The Problem: Dynamic CMS and Public Exposure

In a typical setup, WordPress:

Produces content
Stores content
Serves content directly to end users

In enterprise environments, this creates several risks:

A large attack surface (PHP runtime, plugins, admin panel)
Performance degradation under traffic spikes
Content management and content delivery tightly coupled

The key objective of this project was clear:

Strictly separate content management from content delivery.

The Solution: WordPress and Static Site Separation

Roles were deliberately split across the architecture.

The Role of WordPress

Manages editorial workflows
Produces content
Exports content as ZIP files
Exposes a read-only API listing available exports

WordPress:

Does not serve content
Does not handle traffic
Does not maintain runtime state

The Role of the Static Website

Delivers content to end users
Consists purely of HTML, CSS, and JavaScript
Runs without PHP, databases, or server-side logic

As a result:

The attack surface is drastically reduced
Performance becomes independent of traffic volume

Content Synchronization and Internal Network Security

Content produced in WordPress is handled by a dedicated Content Sync Service:

Periodically checks the export list
Detects new ZIP packages
Uses Redis-based locking to prevent duplication
Transfers ZIP files into the internal network
Extracts content and produces static site output

In this model:

WordPress never accesses the internal network
Internal systems are never exposed publicly
Data flow is strictly one-directional (pull-based)

This aligns well with enterprise IT and information security best practices.

Performance

Performance gains come directly from architectural decisions:

A single ZIP transfer instead of thousands of files
Static assets served from disk or CDN
Complete removal of PHP execution and database queries

As a result:

Initial load times are minimal
Traffic spikes do not impact performance
User experience remains consistent

Security

From a security perspective, the architecture ensures:

No executable backend on the public website
WordPress is fully isolated from content delivery
Content processing remains within the internal network
State and synchronization are centralized and controlled

This provides a clear answer to a critical question:

Even if WordPress is compromised, the static site and internal network remain unaffected.

Dynamic Search on a Static Site (with Algolia)

The only dynamic feature on the static website is search functionality, implemented using Algolia.

Content is produced in WordPress and published as static files
The same content is indexed in Algolia
The static site queries Algolia via JavaScript

From the user’s perspective:

Instant search results
Filtering capabilities
Smooth navigation experience

From a technical standpoint:

No backend runtime
No application state
No direct connection to WordPress

Users experience a dynamic interface while actually browsing a fully static website.

Conclusion

With this architecture:

WordPress was simplified
Content delivery became fully static
Security and performance were achieved together
The system became suitable for enterprise-scale use

After the architectural change, the website’s loading performance improved by 45%.

In short:

WordPress produces content, the static site delivers it, and users never interact with WordPress directly.

Reduce OpenAI Costs by 80%: TOON Reality + Two-Stage Architecture

cenk — Mon, 01 Dec 2025 15:57:12 +0000

🎯 Introduction

TOON is popular but not always optimal for nested structures. Real savings come from architectural optimization.

This article includes:

A brief TOON evaluation
A two-stage architecture reducing costs by 80%
A full fake-data pipeline example

🔍 TOON Summary

Great for flat data
Less efficient for nested structures
JSON Compact often performs better
Biggest savings come from sending less data to the LLM

⚡ Two-Stage Architecture

1️⃣ Minimal Extraction (LLM)

Only tender_id and bids extracted.

2️⃣ Local Enhancement (Zero Tokens)

Addresses, licenses, and numeric values processed locally.

📁 Fake Data Example Pipeline

1️⃣ input.md

AGENCY: Example Transportation Authority
PROJECT ID: 00-X00001
COUNTY: NORTHFIELD

**Bidder 1:** Alpha Infrastructure Group
Address: 101 Example Road, Eastville, EX 90001
Phone: (555) 100-2000
License: FAKE12345
Total Bid: $1,234,567.89

2️⃣ minimal_schema.json

{
  "type": "object",
  "properties": {
    "tender_id": {"type": "string"},
    "bids": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "firm": {"type": "string"},
          "amount": {"type": "string"}
        },
        "required": ["firm", "amount"]
      }
    }
  },
  "required": ["tender_id", "bids"]
}

3️⃣ llm_output.json

{
  "tender_id": "00-X00001",
  "bids": [
    {"firm": "Alpha Infrastructure Group", "amount": "$1,234,567.89"}
  ]
}

4️⃣ enhanced_output.json

{
  "tender_id": "00-X00001",
  "bids": [
    {
      "firm": "Alpha Infrastructure Group",
      "amount": {
        "raw": "$1,234,567.89",
        "numeric": 1234567.89,
        "currency": "USD"
      },
      "address": {
        "street": "101 Example Road",
        "city": "Eastville",
        "state": "EX",
        "zip": "90001"
      },
      "license": "FAKE12345",
      "phone": "(555) 100-2000"
    }
  ]
}

🧠 Conclusion

This architecture:

Reduces cost by 80%
Performs faster
Scales effectively

A Python Tool That Simplifies Access to THE World University Rankings Data

cenk — Sat, 22 Nov 2025 18:45:44 +0000

A practical solution for competitive analysis in younger universities

For many young universities, strategic goals include positioning themselves in the THE World University Rankings, understanding their competitors, and monitoring changes over the years. However, obtaining structured ranking data is not as easy as it seems.

This project was created to solve exactly that problem:

to retrieve THE ranking data via an API and provide it in a clean, integrable format for institutional systems.

🎯 Who Is This Project For?

Academics
Administrative research staff
Strategy and quality offices
Higher-education data analysts

🔍 Technical Overview

Python-based tool
Fetches data from the backend API of THE
Outputs JSON files
Modular structure

⚙️ Installation

git clone https://github.com/c3nk/THE-World-University-Rankings
cd THE-World-University-Rankings
pip install -r requirements.txt
python main.py

🧩 What This Tool Does Not Do

No charts or dashboards
No automated analytics
No interpretation of THE data

🏁 Conclusion

With this tool, accessing THE data becomes:

One-command simple
Clean and structured
Ready for integration

Repo: https://github.com/c3nk/THE-World-University-Rankings

Building a Lighthouse Performance Monitor: Tracking Web Performance Over Time

cenk — Sun, 02 Nov 2025 09:47:00 +0000

The Challenge: Measuring Performance Impact of Major Changes

When our team decided to overhaul both our website's frontend interface and Content Management System (CMS), we faced a critical question: How would we measure the performance impact of these changes?

Google's Lighthouse is an excellent tool for performance auditing. You run it, get your scores, and see what needs improvement. But here's the problem: Lighthouse gives you a snapshot, not a story.

When you're planning major changes like a complete CMS migration or frontend redesign, you need more than point-in-time measurements. You need:

Historical data to establish baseline performance
Trend analysis to spot gradual improvements or regressions
Before-and-after comparisons that show real impact
Long-term monitoring to catch seasonal variations and unexpected changes

That's why I built the Lighthouse Performance Monitor - an automated tool that transforms Lighthouse from a one-time audit tool into a continuous monitoring solution.

The Solution: Automated Daily Monitoring with Visual Trends

The Lighthouse Performance Monitor is a lightweight automation wrapper around Google's Lighthouse that:

Runs daily automated audits using cron jobs
Stores historical data in JSON and CSV formats
Generates visual trend charts showing performance over time
Tracks all key metrics: Performance, Accessibility, SEO, and Best Practices

Real-World Benefits for Product Managers and Developers

For Product Managers:

Data-driven decisions: See exactly how your redesign affected performance metrics
Stakeholder reporting: Beautiful visualizations that clearly show trends over months
ROI justification: Prove that performance improvements directly result from your investments
Risk mitigation: Catch performance regressions before they impact users

For Frontend Developers:

Continuous feedback: Know immediately if your changes hurt performance
Debugging insights: Pinpoint when performance degraded and correlate with deployments
Optimization tracking: Watch your optimization efforts pay off over time
Seasonal patterns: Understand how your site performs during high-traffic periods

A Practical Use Case: The CMS Migration Journey

Let me share a practical scenario that mirrors the motivation behind this tool:

Week 1-4 (Baseline Period)

Run daily Lighthouse audits on existing site
Establish baseline: Performance 65, Accessibility 88, SEO 92, Best Practices 79
Identify current pain points and optimization opportunities

Week 5-8 (Migration Phase)

Continue monitoring as CMS migration begins
Notice gradual changes as content is moved to new system
Spot unexpected accessibility regressions early (dropped from 88 to 82)
Fix issues before full launch

Week 9-12 (Post-Launch)

Monitor new site's performance stabilization
Final scores: Performance 78, Accessibility 95, SEO 95, Best Practices 88
Clear data showing 20% performance improvement and 8% accessibility boost

Months 3-6 (Long-term)

Observe seasonal traffic spikes (holiday shopping, back-to-school)
Identify that performance drops to 72 during peak periods
Plan infrastructure scaling based on data, not assumptions

Without automated monitoring, these insights would be invisible. You'd only have "before" and "after" snapshots, missing the entire journey and valuable optimization opportunities.

How It Works: Simple Architecture, Powerful Results

The tool uses a hybrid approach combining Node.js and Python:

Daily Cron Job Triggers
        ↓
Node.js runs Lighthouse audit
        ↓
Saves JSON report with timestamp
        ↓
Node.js aggregates all reports into CSV
        ↓
Python generates visual trend charts
        ↓
Beautiful 2x2 grid visualization ready

Key Features:

🤖 Fully Automated

Set it and forget it - runs daily via cron job
No manual intervention needed after initial setup

📊 Visual Insights

2x2 grid charts showing all four metric categories
Min/Max value indicators (green/red dots)
Clear date ranges showing data history

💾 Data Portability

JSON reports for detailed analysis
CSV summary for spreadsheet integration
Easy to integrate with existing monitoring tools

⚙️ Highly Configurable

Change target URL easily
Adjust data storage location
Modify Lighthouse flags (mobile/desktop, throttling settings)

Getting Started in 5 Minutes

The tool is designed for minimal setup friction:

# 1. Clone the repository
git clone https://github.com/c3nk/lighthouse-performance-monitor.git
cd lighthouse-performance-monitor

# 2. Install dependencies
pip install -r requirements.txt
npm install

# 3. Configure your website URL
# Edit Lighthouse Report Script.js and update the domain variable

# 4. Run it!
./run-all.sh

That's it! You'll get your first report and trend chart immediately.

To automate it daily:

# Add to crontab (runs daily at 6 AM)
0 6 * * * /path/to/lighthouse-performance-monitor/run-all.sh >> /path/to/lighthouse.log 2>&1

Why This Approach Works

Leveraging Industry Standards

Rather than building a performance monitoring tool from scratch, this project leverages Google's battle-tested Lighthouse engine. You get:

The same metrics Chrome DevTools uses
Regular updates as Lighthouse evolves
Industry-standard benchmarks
Trusted, reproducible results

Minimal Overhead, Maximum Value

The tool's philosophy is "do one thing well": automate Lighthouse and visualize trends. It doesn't try to be a full APM (Application Performance Monitoring) solution. Instead, it:

Runs lean (minimal server resources)
Stores data locally (no external dependencies)
Outputs standard formats (JSON, CSV, PNG)
Integrates easily with existing workflows

Design Process Integration

This isn't just a monitoring tool it's a design process tool. By running it throughout your redesign or migration project, you:

Make data-informed design decisions
Catch regressions during development
Validate performance requirements before launch
Build institutional knowledge about what affects your metrics

What Could Come Next

While the current version focuses on core functionality, there's room for enhancement:

Alert thresholds: Get notified when scores drop below defined limits
Slack/Email notifications: Push reports to your team automatically
Comparative analysis: Side-by-side comparison of different time periods
Multi-site monitoring: Track multiple websites from one installation
Web dashboard: Interactive UI for exploring historical data
CI/CD integration: Run checks before deploying to production

These features aren't implemented yet, but the foundation is ready for community contributions.

The Hidden Benefit: Seasonal Pattern Recognition

One of the most valuable and unexpected insights from long-term monitoring is seasonal pattern recognition.

In the short term (days or weeks), you can't distinguish between:

Temporary performance fluctuations
Genuine improvements/regressions
Seasonal traffic patterns
Infrastructure issues

But with months of data, patterns emerge:

"Our performance always dips in Q4 due to holiday traffic"
"Accessibility scores correlate with our content team's rotation schedule"
"SEO scores improve gradually after major content updates"
"That 'performance improvement' in March was actually just lower traffic"

These insights are impossible to obtain from one-time audits or even weekly manual checks.

Conclusion: From Snapshots to Stories

Google Lighthouse is powerful, but it's designed for point-in-time analysis. For teams planning major changes - redesigns, migrations, platform upgrades - you need continuous monitoring.

The Lighthouse Performance Monitor transforms Lighthouse from a diagnostic tool into a strategic performance intelligence system. It helps you:

Measure the real impact of your work
Catch problems before users notice
Make data-driven decisions
Build performance culture in your team

Whether you're a Product Manager justifying a redesign investment or a Frontend Developer optimizing for Core Web Vitals, having historical performance data changes everything.

Get Started Today

The project is open source and available on GitHub:
https://github.com/c3nk/lighthouse-performance-monitor

⭐ Star the repo if you find it useful
🐛 Report issues or suggest features
🤝 Contribute improvements
📢 Share with your team

License: MIT (free to use, modify, and distribute)

What performance monitoring challenges are you facing? How do you track the impact of your web development projects? Share your experiences in the comments below!