“Numaralı gözlük kullananlar için özel olarak tasarladığımız ilk yapay zeka temelli akıllı gözlüklerimizi tanıtıyoruz.” diyen Meta, bugün spesifik olarak Ray-Ban Meta Blazer Optics (Gen 2) ve Ray-Ban Meta Scriber Optics (Gen 2) modellerini görücüye çıkardı. EssilorLuxottica iş birliğiyle hazırlanan yeni akıllı gözlükler, 499 dolardan başlıyor ve bünyelerindeki kameralar aracılığıyla hem video çekebiliyor hem de Meta AI’ın görsel soru-cevap sistemine destek veriyor. Neredeyse tüm numaralara uyumlu olduğu aktarılan gözlükler, farklı türde lenslerle tercih edilebiliyor ve mikrofon ile sapa entegre hoparlörlerle geliyor. Akıllı telefonlarla bağlantılı olarak görev yapan gözlüklerin fiyatları, numaralı camlara bağlı olarak değişiklik gösteriyor.

Meta, yeni Ray-Ban akıllı gözlüklerini tanıttı yazısı ilk olarak Teknoloji haberleri – LOG üzerinde yayınlandı.

İlk aşamada 108,7 kWh batarya paketiyle 805 km menzil ve çift motor üzerinden 469 beygir gücü sunan dört çeker iX3 50 xDrive’ı pazara sunan BMW, bugün tamamen elektrikli aracın “iX3 40” versiyonunu duyurdu. Arkadan itişli yeni versiyon 320 beygir güç sunuyor ve 82,6 kWh batarya paketiyle 635 km (WLTP) menzil vadediyor. 300 kW DC şarj destekli model, yaz döneminde 63 bin euro fiyatla satışa sunulacak.

BMW iX3 için alt seviye “iX3 40” versiyonu duyuruldu yazısı ilk olarak Teknoloji haberleri – LOG üzerinde yayınlandı.

Nvidia’nın “şimdiye kadarki en gelişmiş modelimiz” dediği 2. nesil Transformer modeline geçiş yaparak görüntü kalitesini artırırken hayaletlenmeyi azaltan DLSS 4.5 teknolojisi, “Dinamik Çoklu Kare Oluşturma (Dynamic Multi Frame Generation)” isimli bir altyapıyla geliyor. Kare oluşturma modunu istenilen kare hızına göre dinamik olarak ayarlayan sistemi bugün itibarıyla resmi olarak kullanıma sunan Nvidia, aynı zamanda RTX 50 serisi ekran kartlarına DLSS 4.5’in destek verdiği RTX 20, 30 ve 40 serilerinden farklı olarak “6x” seviyesinde “Çoklu Kare Oluşturma” imkanı sunmaya da başladı. Çoklu kare oluşturma teknolojisi, yapay zekadan yardım alarak birden fazla kare oluşturuyor ve gecikmeyi biraz artırıyor olmasına rağmen kare hızlarını (fps) önemli ölçüde yükseltebiliyor. 4K’da 240 Hz oyunculuğu hedefleyen yeni 6x modu, işlenen her bir kare için beş ek “sahte” kare oluşturuyor. DLSS 4.5, Nvidia’nın resmi PC uygulaması aracılığıyla 400’den fazla yapımda kullanılabiliyor ve oyunlar uygulama üzerinden 4.5 ile çalışması için zorlanabiliyor.

Nvidia, beklenen yeni DLSS 4.5 teknolojilerini kullanıma sundu yazısı ilk olarak Teknoloji haberleri – LOG üzerinde yayınlandı.

The illustration of the city above is all CSS. There are no images, no SVG, no JavaScript… there isn’t even any HTML!*

Here’s the source code on CodePen:

(Click on the 1x, 0.5x, and 0.25x buttons to zoom in or out and see more of the illustration. Alternatively, you can also visit the CodePen details page, where you can zoom in/out and resize the window for better results)

You may ask “how did you do it?” And the answer will be “with a lot of patience.” I started this CSS Art two years ago, and worked adding small things little by little: a building here, some tree there, a bus stop close by… But, due to personal and professional reasons, I stopped adding things around a year ago, and haven’t touched the code since. I’d love to expand it into a full city someday.

Basically, it is all a big collection of CSS gradients: radial, linear, conic… I event used the repeating ones. All of them sized and positioned so they fit within a particular spot in the illustration.

This drawing is different from other CSS Art I usually do. I tend to do small things that are responsive, but this is an infinite drawing and it uses absolute units.

It is infinite because it doesn’t matter how much you resize, the illustration just goes on and on. This was achieved by playing with background sizes and positioning, so the same elements repeat ad infinitum. Examples of these elements are:

• The bricks on the wall
• The tree tops behind the wall
• The grayed buildings in the very background
• The park houses

The absolute units are pixels, and I used that instead of vmin or em, to make sure that all the things will fall exactly in the place I wanted them to be. When using relative units, sometimes something will fall in a half a pixel position and the result looks off.

When drawing and adding elements, I started from the bottom center of the image, and position everything based on that point, growing from there upwards and sideways.

I added some basic animations (but commented them for performance while coding, you can uncomment the code, but it’s not much), so the traffic light actually works, the water in the fountain flows (poorly) or some of the lights flicker. I considered adding a car that stops at the traffic light and an UFO that flies above the city –that won’t be seen unless you zoom out considerably or have a large/tall screen.

And all this using just the :root element. I could still use the ::before or ::after pseudo-elements to do add more things. In particular, animated things. But I dropped the idea because adding them caused the performance to drop considerably. Still, I would like to continue adding more things when I have time.

What do you think? Have you ever done a single div CSS Art?

*The CodePen demo may not show any HTML, but it automatically adds a structure that is hidden from view but can be seen reviewing the source code. There is a way to run CSS on the browser without the need to import it from HTML. Unfortunately, it requires updating some settings in the web server, and only one browser supported it last time I checked (Firefox). If we did this, the illustration would be completely CSS only.

I’ve been a CTO long enough to have onboarded dozens of developers across teams of varying maturity. The pattern that works has never changed: a new developer reads existing documentation, explores the repository, implements small tasks – often ones designed by a senior to expose how the system’s key features work.

How is the API structured?
Where does state live?
How do data flows connect?

The developer learns by doing, making mistakes, and reflecting on what went wrong.

AI hasn’t killed that process. But poorly thought-through adoption of AI has made it much harder for developers to learn a project and the logic behind it. When a developer delegates everything to an AI assistant without reflection and when AI implements the onboarding task, the developer just submits the PR – the task got done, but the onboarding didn’t happen. The developer no longer learns from mistakes or learns by discovery, because there were no mistakes to learn from and nothing to discover.

That’s not an AI problem. It’s a process problem.

The productivity question

AI tools make developers faster. But the gains aren’t as straightforward as the headlines suggest.

Less experienced developers often see the largest raw productivity gains. They can produce working code faster than ever before. But the quality and sustainability of that output depends almost entirely on the process around them.

With good onboarding, clear guardrails, and access to company context, a developer using AI performs significantly better than one without it. In a less structured environment, the results can go sideways quickly. Developers who haven’t yet built strong engineering instincts may accept any AI suggestion without reflection because they don’t have the experience to question what looks correct but isn’t.

Senior engineers, by contrast, tend to capture a reliable productivity uplift regardless of process maturity. They already have the judgment to validate, reject, or reshape AI output. The difference isn’t the tool. It’s whether the organization has invested in the process to support it.

Three patterns worth watching

These aren’t new failure modes created by AI. They’re existing risks that AI makes faster and less visible.

The reload loop

When AI-generated code breaks, there’s a natural instinct to copy the error back into the chat. A patch arrives. Another error. Repeat. This is a human psychology problem when presented with solutions time after time, people tend to switch off and keep reloading. If something doesn’t work after implementation, it usually signals a gap in project comprehension, not a missing patch. The right response is to step back: trace the data flow, read the related tests, understand the code surrounding the problem. Without that comprehension, both the AI and the developer produce shallow fixes that mask the real issue.

Architecture drift

AI can assist with architectural work, but only when it has proper project context. Without it, developers treat a codebase as a collection of independent prompts rather than a coherent whole. Libraries get introduced for problems that already have internal solutions. Patterns multiply. Data flows become harder to trace. The real challenge is preserving architectural knowledge across AI sessions. Decisions and conventions need to persist between conversations, and that requires deliberate documentation, not just good intentions.

Uncritical acceptance

Developers sometimes accept AI-generated code because it looks right. The output has a confident, professional structure. Developers who haven’t yet built strong debugging instincts may trust polish over correctness, including code with security vulnerabilities. The mitigation is the same as it’s always been – senior review at the PR stage. But it can also be addressed earlier, during refinement, by identifying security-sensitive areas and including specific checks in the task definition.

Across all three patterns, one thing is conspicuously absent from most discussions – automated guardrails. Linters, type checking, CI/CD pipelines, unit tests – these catch entire categories of problems before any human reviews anything. A conversation about AI-assisted development that ignores automated safety nets is incomplete.

What’s actually at risk

Every codebase is an artifact of decisions made under pressure. It contains frameworks chosen after failed experiments, workarounds born from production incidents, edge cases that took months to surface, and security patches whose context lives in decision logs.

What healthy organizations do is build infrastructure that makes context accessible, clean consistent architecture with documentation that explains not just what was built but why; and indexed, discoverable component libraries shared across teams.

Even with all of this, there’s knowledge that lives in places humans struggle to navigate, scattered across repositories, buried in years of commit history, distributed across documentation platforms. This is where AI code intelligence platforms add genuine value: collecting unstructured knowledge from across the organization, auto-documenting code, and serving it as context to AI assistants on demand.

Understanding code before generating

Before writing new code, a developer should be able to answer:

Does a solution to this problem already exist in our codebase?
How have other teams handled the same pattern?
What decisions shaped the module I’m about to modify?

AI assistants can answer some of these questions well, especially within a single, small-to-medium-sized repository. Where it breaks down is across organizational boundaries: multiple repositories, years of accumulated history, cross-team conventions, decisions that were never documented in code. That’s where additional context layers change the equation.

Consider a developer implementing retry logic for a billing service. A general-purpose AI assistant working within the current repo will produce a functional, contextually grounded implementation. But if the best reference implementation lives in a different repository, a RetryStrategy class written by a staff engineer for another service eight months ago, a single-repo tool won’t surface it. A code intelligence platform that indexes across repositories can. The developer gets the class, it’s calling context, the middleware it connects to, and the logging conventions the team adopted.

That’s valuable. But it’s not the end of the story. The solution was created in a different system, and not everything will translate directly. It’s the developer’s job to understand the pattern and work with their AI assistant to adapt it. The platform provides compressed discovery, not compressed implementation. Human understanding remains the critical step.

What actually helps? Building an organizational system

Individual habits like “check if this exists elsewhere” are fine advice, but they rely on personal discipline and don’t scale. What works is building organizational infrastructure that makes good practices the default.

Layer 1: Automated guardrails.

Linters, formatters, type checking, testing strategies. These catch problems before any human reviews anything and encode team standards into automation. This is the foundation, and it costs zero effort per task once configured.

Layer 2: AI configuration infrastructure.

This is where most organizations have untapped potential. AI assistants can be configured with system instructions that encode your team’s conventions, architectural principles, and preferred patterns. Sub-agent definitions and skills libraries can capture tribal knowledge in a form that AI can use during code generation. Written decision logs and architectural guidelines become prompts, not just documents.

Critically, developers need to understand how AI assistant memory works so that decisions and context persist between sessions. Without this, every AI conversation starts from zero and accumulated understanding is lost. Organizations should treat AI session configuration: memory, context documents, progressive context building, as part of their development infrastructure, not as something each developer figures out on their own.

Layer 3: Knowledge aggregation.

Code intelligence platforms indexing across repositories. Documentation platforms connected and searchable. The goal is that when a developer asks “how do we handle this pattern?” the answer draws from the entire organization’s experience, not just the current repo.

Layer 4: Feedback loops.

This is what makes the whole system improve over time rather than decay. Guardrails and linting rules are updated on a regular cadence. Instruction libraries, prompt templates, and skills definitions are refined based on outcomes. Code intelligence platform searches and recommendations improve through feedback. Documentation, tests, and architecture decision records are generated with AI assistance and kept current.

Here’s the key insight: AI both creates the context problem and provides the solution. Writing good documentation, thorough tests, and clear ADRs used to be expensive and time-consuming, so teams skipped it. Now AI makes it fast. We just need to build the infrastructure to capture that context and establish the feedback loops so it improves itself over time.

The real gap

The productivity difference between a new developer and an experienced one exists because experienced engineers have contextual maps built over years. AI can generate output that looks senior-level without building any of that understanding.

When evaluating AI tooling for your team, the right question isn’t “how much code does it generate?” It’s “how much does it help developers understand the system before changing it?”

AI doesn’t replace the journey from new team member to trusted contributor. With the right process: structured onboarding, automated guardrails, well-configured AI tools, organizational knowledge made accessible, and continuous feedback loops; it compresses that journey. Developers onboard in weeks instead of months because they’ve understood the system’s history and patterns, not because they’ve generated their way past them.

Not faster output. Better understanding, at speed.

Thoughts, pushback, and real-world examples welcome in the comments.

Today’s session was a mix of core Java fundamentals + tricky logic + real-world usage 💡
We explored how conditions work, how loops behave without braces, user input handling, and even touched JSON/XML basics.

Let’s break it down step by step 👇

🔹 1. Condition Must Be Boolean (True/False)

In Java, every condition must return either true or false.

❌ Invalid Example

int i = 1;
while(i) {   // ❌ Compilation Error
    System.out.println(i);
}

👉 Why error?

• Java does NOT allow non-boolean conditions
• Unlike C/C++, numbers are not treated as true/false

✅ Correct Example

int i = 1;
while(i <= 5) {
    System.out.println(i);
    i++;
}

✔ Condition → i <= 5 → returns boolean
✔ Hence valid

🔹 2. True / False Direct Conditions

You can directly use true or false in conditions.

✅ Example

if(true) {
    System.out.println("Always runs");
}

✔ Output:

Always runs

❌ Example

if(false) {
    System.out.println("Never runs");
}

✔ Output:

(no output)

👉 This is useful for testing or debugging

🔹 3. Removing Curly Braces { }

Java allows skipping { } if only one statement is present.

✅ Example

for(int i = 1; i <= 5; i++)
    System.out.println(i);

✔ Output:

1 2 3 4 5

⚠️ Tricky Case

for(int i = 1; i <= 5; i++)
    System.out.println(i);
    System.out.println("Done");

✔ Output:

1 2 3 4 5
Done

👉 Only the first statement is inside loop
👉 Second statement runs once after loop

🔹 4. Infinite Loop (By Default True)

If condition is always true → loop never stops 😱

Example

for(;;) {
    System.out.println("Infinite Loop");
}

👉 This is equivalent to:

while(true) {
    System.out.println("Infinite Loop");
}

✔ Used in:

• Servers
• Continuous monitoring systems

🔹 5. break and continue

🔸 break → stops loop completely

for(int i = 1; i <= 5; i++) {
    if(i == 3)
        break;
    System.out.println(i);
}

✔ Output:

1
2

🔸 continue → skips current iteration

for(int i = 1; i <= 5; i++) {
    if(i == 3)
        continue;
    System.out.println(i);
}

✔ Output:

1
2
4
5

🔹 6. Taking Input from User (Scanner)

To read input in Java, we use Scanner.

Example

import java.util.*;

public class Test {
    public static void main(String[] args) {
        Scanner sc = new Scanner(System.in);

        System.out.print("Enter your name: ");
        String name = sc.nextLine();

        System.out.println("Hello " + name);
    }
}

⚠️ Important Notes

❌ Java does NOT directly support char input
✔ Workaround:

char ch = sc.next().charAt(0);

✔ For String:

String name = sc.nextLine();

🔹 7. Multiple Inputs Example

Scanner sc = new Scanner(System.in);

System.out.print("Enter Tamil mark: ");
int tamil = sc.nextInt();

System.out.print("Enter English mark: ");
int english = sc.nextInt();

int total = tamil + english;

System.out.println("Total mark: " + total);

✔ Output Example:

Enter Tamil mark: 80
Enter English mark: 90
Total mark: 170

🔹 8. JSON vs XML (Basic Understanding)

🔸 JSON (JavaScript Object Notation)

{
  "username": "Manikandan",
  "password": "1234"
}

✔ Lightweight
✔ Easy to read
✔ Mostly used in APIs

🔸 XML (Extensible Markup Language)

<user>
    <username>Manikandan</username>
    <password>1234</password>
</user>

✔ Structured format
✔ Used in older systems / configs

🔹 9. Do-While Loop

👉 Runs at least once, even if condition is false

Example

int i = 1;

do {
    System.out.println(i);
    i++;
} while(i <= 5);

✔ Output:

1 2 3 4 5

🔥 Key Difference

🧠 Key Takeaways

✔ Condition must always be boolean
✔ Java does NOT allow non-boolean conditions
✔ Without {}, only one statement is considered
✔ Infinite loops happen when condition is always true
✔ break → exits loop
✔ continue → skips iteration
✔ Scanner is used for user input
✔ JSON is lightweight, XML is structured
✔ do-while runs at least once

🏁 Conclusion

Today was all about understanding how Java actually behaves under the hood 🧠

These small concepts are very important when:

• Writing automation scripts
• Handling test data
• Building logic-driven frameworks

🔥 Step by step, building strong fundamentals in automation!

🤖 A Small Note
I used ChatGPT to help structure and refine this blog while keeping the concepts aligned with my learning.