标签：#RAM

I run seven agents over the same domain. They have never once sent each other a message. That was not the plan. The plan was the thing everybody builds first: a coordinator that hands work between specialists, agents that call each other, a shared conversation they all append to. It worked in the demo and it fell apart the moment the work got real. What replaced it is boring and it has held up: every agent writes claims to one shared record, and nothing else. No agent reads another agent's reasoning. No agent can call another agent. The record is the only channel. Here is why, and what it cost. What breaks in the group-chat design Three things, roughly in the order they hurt. Context grows without bound. If agents converse, every agent needs everyone else's output in its window to participate. Six specialists means each one is reading five other monologues. Your token spend goes quadratic in the number of agents and the marginal agent makes the others measurably worse. Errors laminate. Agent B reads agent A's output as input. If A was confidently wrong, B does not treat it as a claim to be weighed — it treats it as context, which is to say, as true. By the time it reaches F you have a well-reasoned conclusion resting on a hallucinated premise, and nothing in the transcript flags where the floor gave way. You cannot answer "why." Six weeks later someone asks why the system concluded X. The honest answer is "there was a conversation." That is not an answer you can act on, and it is not an answer that survives an auditor. Agents as authors, not as callers The reframe that fixed it: an agent is not a function other agents invoke. An agent is an author with a domain of authority . Each of mine owns a slice of the problem and may only make claims inside it: Agent Domain Claims it may make Verification What is true about the thing today Observed facts, source records, reconciled geometry Design What it should become Plan gaps, code compliance, takeoffs Recovery What can be

I've built enough animated portfolio sites and agency landing pages at this point that I can usually tell within the first three seconds of scrolling whether a site was built by someone who actually understands scroll animation, or someone who just copied a GSAP tutorial and called it a day. And honestly, for a long time, I was the second guy. I remember the first time I tried to recreate one of those Awwwards style hero sections, the ones where text fades and slides as you scroll and everything feels buttery and expensive. I copied the GSAP code almost exactly from a tutorial. Same triggers, same easing, same everything. On my laptop, using my trackpad, it looked incredible. I was proud of it. Then I opened it on my client's Windows machine with a regular mouse, and it looked like it was having a seizure. Stuttering, jumping, completely different animation than what I built. That was the moment I realized the problem was never really the animation. The problem was what the animation was reading from. That thing is scroll. And native browser scroll is honestly kind of a mess. Why native scroll ruins your animations Here's the part nobody explains properly when they show you a GSAP demo. When you scroll a normal webpage, the browser doesn't give you a smooth continuous stream of scroll position. It gives you scroll position in little discrete jumps. How big those jumps are depends on the device, the input method, the browser, even the operating system. A trackpad on a Mac behaves differently than a mouse wheel on Windows, which behaves differently again on a touchscreen. Now think about what ScrollTrigger is actually doing under the hood. It's constantly reading your scroll position and mapping it to animation progress. If the scroll position itself is jumpy and inconsistent, then no matter how well you write your animation code, the output is going to inherit that same jumpiness. You could have the most perfectly tuned easing curve in the world and it still won't ma

What started as "translate dialogs in a Korean game without alt-tabbing to Google Translate" became a rewrite of my screenshot toolchain. A few months later, one app: Capture area, window, or fullscreen Copy the text out of any screenshot, like it were a document Translate a foreign-language screenshot in place, offline Long pages stitch into one tall image Screen record with a camera bubble What I'm most happy with: zero network calls for reading and translating text. Screenshots carry API keys, client work, personal chats. Mine never left the Mac, and that felt like the right default for everyone's. Tech notes, happy to go deeper in comments: Pure Swift and SwiftUI, no Electron. About 25MB Apple's Vision framework for reading text. Genuinely scary good for how cheap it is One hotkey, everything else lives in menus Building in public. How you extract text from screenshots today would help me know what to chase next. Trial: https://ishot.buzz?utm_source=devto

submitted by /u/soap94 [link] [留言]

I haven't written an article in a while. But nothing gives you more inspiration to write than an opinion you really, really disagree with. In my case it was I'm done using AI article by Brett Codes. Over around 2000 words, the author explains his negative views on AI and why he decided to stop using it . I am really no AI evangelist. I am aware of its limits and its problems and the incompetent people causing more harm than good with it. But I also see the goodies, and I am pretty much convinced author's decision was driven less by rationality and more by the false pride. Let's swallow one bitter, but important pill - no one is paying you solely for being a good developer. You are being paid for delivering a value. And yes - being a good developer greatly contributes towards the ability of delivering apps that work and help businesses yielding the values. And by "work" I mean not only they look good at the first glance, but also being not (too much) buggy, secure and maintainable in the foreseeable future. Therefore, purely vibe-coded projects driven solely by non-IT people often (if not always) fail. Because their authors don't know what it takes and so they cannot prompt their agents to reason and care about it. We devs do. Some of us know more, some of us know less (yet). The "AI is going to replace all programmers" is a lunatic nonsense. But so is rejecting AI and sanctifying "good ol' hand work" . Does anyone seriously think we should reject modern programming languages and revert into writing in assembly or even better directly in binary code? Do you develop in plain text editor without syntax highlighting? Why are you using containers and not building new on-premise servers every time? Whaat? You use frameworks and 3rd party libraries? You don't implement everything from scratch in the vanilla language? Seriously? Why all those abstractions and shortcuts? They make you lazy and they obfuscate the true principles, aren't they? You are a worse developer if you

Managing files, running scripts, and executing terminal commands on your smartphone from a computer is much more convenient through a full SSH session, eliminating the need to switch between device screens. ​Installing OpenSSH Open Termux and install the package for the secure protocol: pkg update && pkg install openssh Configuration ​Set a password to secure the connection: passwd ​ Find your current username using the whoami command (usually looks like u0_a... ). ​Start the SSH server: sshd ​Connecting from a PC Find your smartphone's local IP address using ifconfig (look for the inet line under the wlan0 interface). Note that Termux uses a non-standard port 8022 by default instead of the standard 22. Connect from your computer (Linux, macOS, or Windows via PowerShell/PuTTY): ssh <username>@<smartphone_IP> -p 8022 After entering your password, you will gain full access to your phone's terminal directly from your PC. Autostarting the Server To avoid starting the server manually every time you open the app, add the command to your shell configuration: echo "sshd" >> ~/.bashrc This tool turns your mobile device into a fully functional remote node that is easy to manage over the local network when developing and testing lightweight projects. I share more simple and awesome smartphone IT projects on my Telegram channel: @termuxq

submitted by /u/davidalayachew [link] [留言]

TL;DR — I put an AI code reviewer on a pull request written by an AI coding agent. On the default setting it found nothing. On the strict setting it found a real vulnerability. And the patch it offered would have quietly broken every negative number in the exported file. I ship small browser tools written by Claude Code, and I am not a good enough reviewer to catch a security bug in code I did not write. That is the awkward kind of gap: the code looks fine, the page works, the tests pass. So I installed CodeRabbit on the repository and gave it something real to read: a CSV export for a pricing calculator. One row per material line, then other costs, total cost, selling price, profit, margin. About sixty lines of vanilla JS. My own checks passed first — a static site audit, plus a headless browser run of the tool, 14 of 14. Round 1: silence No actionable comments were generated in the recent review. That is the default. CodeRabbit ships a review profile called CHILL , tuned not to nag. For a team drowning in review comments that is probably right. For someone who cannot fully audit their own code, silence is the least useful answer available. So I committed a config file: # .coderabbit.yaml reviews : profile : assertive Same commit. Same diff. Same reviewer. Only the setting changed. Round 2: a real bug, checked the hard way The strict pass flagged CSV formula injection (CWE-1236) , and it was right. A spreadsheet treats a cell that begins with = , + , - or @ as a formula. Name a product =1+1 , export it, and the number two appears in the file the other person opens. Pick a nastier formula and it stops being a curiosity. My csvCell() escaped quotes and commas correctly and did nothing at all about this. What surprised me was how it checked. Folded into the comment was a shell command it had actually run against the repo — a ripgrep over every place a product name or unit flows into the exporter — to see whether something upstream already sanitised the value. It did n

Code: Megapixel99/lambda-language lm is a small low-level language I wrote: static types, explicit memory, no closures, no garbage collector, and four independent backends that emit C, WebAssembly, ARM64 and bytecode for a VM. Its compiler is about 4,400 lines of JavaScript. The obvious next question is whether the language can compile itself, and the obvious first step is the lexer, which is 129 lines. In lm the same lexer is 355 lines. That ratio is the finding, because almost none of it is lm being a verbose language. Six specific absences account for nearly all of it, and writing them down was a planned milestone rather than an afterthought: the point of porting the lexer first was to find out what the language could not do while the port was still small enough to abandon. The one that cost the most src/lexer.js has a single advance(n) that moves pos , line and col together, called from 14 places. lm had no way to take the address of a scalar local, so a function could not mutate a caller's variable, and a function returning three values would need a struct allocated on every call. So advance does not exist. All 14 sites write pos += 1; col += 1; inline, and the newline case writes the three-line variant. That is the single largest source of the size difference, and it also caused the only correctness bug in the port. Column counting inside a string literal has to skip UTF-8 continuation bytes, and because the logic is inlined rather than centralised there is no one place to fix it. The two comment scanners over-count a column in exactly the same way. They get away with it only because a comment always ends at a newline, which resets the column before anything reads it. That is worth sitting with. A centralised advance would have been fixed once and been right in all three places. Instead the code is right in one place by correction and in two others by luck, and the luck is load-bearing: change what terminates a comment and two latent bugs become live ones. Dup

Are you pushing your body to the limit or just driving it into the ground? In the world of high-performance athletics and biohacking, Heart Rate Variability (HRV) has become the "North Star" for recovery. But raw numbers from your Garmin or Oura Ring only tell half the story. To truly understand the relationship between sleep quality , exercise load , and stress perception , we need more than a dashboard—we need a predictive pipeline. In this tutorial, we will build a multi-dimensional analysis system using Scikit-learn , LSTM (Keras) , and the Terra API to predict overtraining risks. By the end of this guide, you'll know how to turn messy wearable data into actionable health insights. The Architecture: From Bio-Signals to Insights To handle the complexity of time-series data (HRV) and categorical features (activity types), we use a hybrid approach. We use Random Forest to identify which lifestyle factors impact recovery the most and LSTM to predict future HRV trends based on historical sequences. graph TD A[Garmin / Oura Ring / Apple Watch] -->|Webhook| B(Terra API) B --> C{Data Preprocessing} C -->|Feature Engineering| D[Random Forest Classifier] C -->|Sequence Processing| E[LSTM Neural Network] D -->|Feature Importance| F[Stress Analysis Engine] E -->|Trend Prediction| F F --> G[FastAPI Endpoint] G --> H[End User Dashboard] Prerequisites To follow along, you'll need: Terra API Keys : For unified access to wearable data (Garmin, Oura, etc.). Tech Stack : Python 3.9+, Scikit-learn, Keras/TensorFlow, and FastAPI. The Mindset : A passion for Health Tech and Wearable Data Science . Step 1: Ingesting Data with Terra API Standardizing data across different wearables is a nightmare. The Terra API acts as an abstraction layer, giving us a unified JSON structure for heart rate, sleep, and activity. import requests def get_wearable_data ( user_id , start_date ): # Using Terra API to fetch aggregated daily health data url = f " https://api.tryterra.co/v2/daily?user_id= { use

บทวิเคราะห์ "Agentic Software", paper ที่เลิกใช้ชื่อ "The End of Software Engineering" เพื่อเล่าเรื่องวิชาใหม่ที่กำลังเกิด โดย Nokka (นก-กา), นักเขียนอิสระสายเทคโนโลยี ผู้เขียนบทความอธิบายเทคโนโลยีให้คนทั่วไปเข้าใจ 30+ บทความบน dev.to | 5 กันยายน 2026 บทความนี้เขียนโดย AI (glm-5.3 via ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์, Nokka (นก-กา), อ้างอิงจาก paper วิจัยบน arXiv ฉบับเต็ม (2606.05608v1) ของ Zhenfeng Cao มี paper หนึ่งบน arXiv ที่จัดเป็นประเด็นที่สุดของปีหนึ่งงาน: "Agentic Software: How AI Agents Are Restructuring the Software Paradigm" โดย Zhenfeng Cao จาก Lingxi Intelligent Investment เมืองเสิงเจ๋น [1] เกร็ดที่ทำให้ paper นี้น่าสนใจกว่าชื่อที่เห็นคือมันเคยใช้ชื่อห้าวห้าสุดมาก่อน: ฉบับแรก (v1, มิ.ย. 2026) มีชื่อว่า "The End of Software Engineering: How AI Agents Are Fundamentally Restructuring the Software Paradigm" ก่อนผู้แต่งจะตัดคำว่า End ทิ้งเองใน v2 ซึ่งออกมาหกวันต่อจาก v1 พอดี เหมือนยอมรับว่าคำนั้นกลายเป็นการตัดสินประเด็นเกินเนื้อหาจริง เรื่องนี้ไม่ได้แค่เล่าจับฉาก แต่มีโครงเหตุผลจริงเป็นสามชั้น: วิชา software engineering เกิดจากข้อตั้งต้นหนึ่งที่ใช้มา 50 ปี, ข้อตั้งต้นนั้นกำลังหมดความหมายเพราะ agent, และสิ่งที่จะเกิดขึ้นแทนมีชื่อใหม่ที่ผู้เขียนเรียกว่า Agentic Engineering บทความนี้พาไล่ดูตามเหตุผลของเขาทีละชั้น พร้อมบอกด้วยว่าจุดไหนควรเชื่อแค่ไหน ก่อนอื่น, ทำความเข้าใจศัพท์ Software engineering : วิชาวิธีสร้างซอฟต์แวร์อย่างเป็นระบบ เกิดเป็นศัพท์ทางการที่ประชุม NATO ปี 1968 จากวิกฤต "ซอฟต์แวร์บวม" ของยุคนั้น AaaS (Agent-as-a-Service) : ศัพท์ที่ paper ตั้งใหม่ สำหรับยุคที่ผู้ใช้จ่ายเงินแลก "ผลลัพธ์จาก agent" ไม่ใช่ "ชั่วโมงหรือสิทธิ์ใช้ซอฟต์แวร์" Intent architect : บทบาทมนุษย์ยุคใหม่ที่ paper ทำนาย คนที่เขียน "เจตนา" ให้ชัดพอที่ agent จะเอาไปรันได้ แทนการเขียนโค้ดเอง ถ้าให้อุปมา: วิชาเดิมเหมือนวิชา "สถาปัตรกรรมสำหรับอาคารอิฐ" ที่สอนว่าจะกออิฐทีละก้อนอย่างไรให้บ้านไม่พัง วันหนึ่งปรากฏเครนอัตโนมัติที่รับแบบจากคำบอกของเจ้าของบ้านแล้วสร้างเองได้ทั้งหลัง วิชากออิฐยังมีคนใช้อยู่ แต่คำถามสำคัญที่สุดของวิชาย้ายจาก "กอยังไงไม่ให้พ

ช่องว่าง 0.3% แต่ราคาต่าง 2 เท่า, อ่านตาราง Terminal-Bench 4.0 ให้เป็น โดย Nokka (นก-กา), นักเขียนอิสระสายเทคโนโลยี ผู้เขียนบทความอธิบายเทคโนโลยีให้คนทั่วไปเข้าใจ 30+ บทความบน dev.to | 5 กันยายน 2026 บทความนี้เขียนโดย AI (glm-5.3 via ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์, Nokka (นก-กา), อ้างอิงจากตาราง leaderboard จริงของ Terminal-Bench 4.0 และข้อมูลราคาจาก TokenCost สัปดาห์นี้ตาราง Terminal-Bench 4.0 มีโมเดลใหม่สองตัวขึ้นครองสองอันดับแรกพร้อมกัน: GPT-6 Astra ผ่าน Codex อยู่ที่ 58.2% และ Claude Fable 5.1 ผ่าน Claude Code ตามติดที่ 57.9% [1] พาดหัวข่าวส่วนใหญ่เล่าเรื่องความเก่ง แต่ผมอยากชวนอ่านตารางนี้ให้ลึกกว่านั้น เพราะคอลัมน์ที่อยู่ขวาสุดของตารางคือสิ่งที่นักพัฒนาตัวจริงควรจ้อง: ต้นทุนต่อรันเต็ม ทั้งสองตัวต่างกันแค่ 0.3 จุดในคะแนน แต่ต่างกันเกือบสองเท่าในเงิน: รันเต็มชุดของ Astra ใช้ประมาณ 3,300 ดอลลาร์ ขณะที่ Fable 5.1 ใช้ราว 6,200 ดอลลาร์ [1] บทความนี้เล่าว่าภาพนี้บอกอะไรเกี่ยวกับตลาดโมเดลปี 2026 และจะอ่านตาราง benchmark แบบนี้ให้เป็นยังไง ก่อนอื่น, ทำความเข้าใจศัพท์ Terminal-Bench : benchmark ที่วัดโมเดลผ่านงานจริงใน terminal ลีนุกซ์ เช่น ตั้งเครื่อง แก้ไฟไฟล์ config รันโค้ด จัดการ process เกินกว่าการตอบคำถาม รันเต็ม (full run) : การวิ่งโมเดลผ่านทุกโจทย์ในชุดหนึ่งรอบ เงินที่เห็นคือค่า API รวมของรอบนั้น ค่าความไม่แน่นอน (± ) : ตัวเลขหลังคะแนนบอกว่าถ้ารันใหม่ผลอาจลอยไปเท่าไหร่ เช่น 58.2% ± 2.8% หมายถึงอยู่ระหว่างราว 55-61% ถ้าให้อุปมา: ตารางนี้เหมือนตารางแข่งรถที่ป้ายบอกแค่เวลาเข้าเส้นชัย แต่สิ่งที่ลืมดูคือราคาน้ำมันที่แต่ละคันกินต่างกันเท่าตัว เวลาเข้าเส้นชัยต่างกัน 0.3 วินาทีไม่ได้แปลว่าคุ้มกันเสมอ ถ้าคันหนึ่งกินน้ำมันแพงกว่าสองเท่า ตารางจริง 14 อันดับ, อ่านคู่คะแนนกับราคา จากตารางทางการ ณ ต้นเดือน ก.ย. [1] อันดับ โมเดล (ผ่าน harness ไหน) คะแนน ราคาต่อรันเต็ม 1 GPT-6 Astra (Codex) 58.2% ± 2.8% $3.3k 2 Fable 5.1 (Claude Code) 57.9% ± 3.8% $6.2k 3 Opus 5 (Claude Code) 51.8% ± 3.4% $6.0k 4 Fable 5 (Claude Code) 44.5% ± 3.8% $7.3k 5 GLM-5.3 (Claude Code) 41.8% ± 3.2% $2.7k 6 GPT-5.6 Sol (Codex) 37.3% ± 3.8% $2.5k 7 Opus 4.8 (Claud

เมื่อ Benchmark โกหกคุณ, SWE-Bench ProMax กับคะแนนจริงที่โมเดลเก่งสุดทำได้แค่ 41.2% โดย Nokka (นก-กา), นักเขียนอิสระสายเทคโนโลยี ผู้เขียนบทความอธิบายเทคโนโลยีให้คนทั่วไปเข้าใจ 30+ บทความบน dev.to | 5 กันยายน 2026 บทความนี้เขียนโดย AI (glm-5.3 via ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์, Nokka (นก-กา), อ้างอิงจาก paper วิจัย SWE-Bench ProMax บน arXiv ฉบับเต็ม เลข 90% ที่ทุกค่าย AI โชว์กันในปี 2026 อาจไม่ได้แปลว่าโมเดลเก่งขนาดนั้น paper วิจัยใหม่บน arXiv เปิดตัว benchmark ชื่อ SWE-Bench ProMax แล้วชี้ตัวเลขที่ต่างจากกระแสโดยสิ้นเชิง: เมื่อวัดด้วยงาน refactor จริงข้ามหลายไฟล์หลายภาษา โมเดลที่ดีที่สุดทำได้แค่ 41.2% [1] แต่ก่อนจะไปถึงตัวเลขใหม่ เรื่องที่ทำให้ paper นี้คุ้มอ่านที่สุดคือส่วนแรก: มันอธิบายว่าทำไมคะแนน benchmark เดิมถึงเชื่อไม่ได้เท่าที่คิด และนี่คือเรื่องเล่าแบบนั้นครับ ก่อนอื่น, ทำความเข้าใจศัพท์ SWE-bench Verified : benchmark เก่าที่ใช้กันทั้งอุตสาหกรรม วัดจาก issue จริงบน GitHub ของโปรเจกต์ Python Gold patch : เฉลยที่นักพัฒนาตัวจริงเคย commit ไว้ใน repository สาธารณะ Data contamination : โมเดลเคยเห็นเฉลยระหว่างเทรนจากข้อมูลสาธารณะ ทำให้ "จำ" ได้แทนที่จะ "คิด" Refactoring : การปรับโครงสร้างโค้ดใหม่โดยพฤติกรรมภายนอกเป็นเหมือนเดิมทุกอย่าง ถ้าให้อุปมา: สนามเดิมเหมือนข้อสอบที่ปล่อยเฉลยไว้ในห้องสมุดสาธารณะมาหลายปี นักเรียนคนไหนตั้งใจท่องห้องสมุดก็ทำข้อสอบได้เกือบเต็ม ส่วนข้อสอบใหม่ของ ProMax คือเขียนโจทย์สดจากงานจริงที่ยังไม่มีใครเคยเฉลยในที่สาธารณะ และบังคับให้แก้ทั้งเมือง ไม่ใช่เพียงบ้านหลังเดียว สามปัญหาที่ทำให้ benchmark เดิมเชื่อไม่ได้ จากการตรวจสอบ (audit) ที่ paper อ้างถึง ปัญหาของ SWE-bench Verified มีสามชั้นที่ซ้อนกัน [1] ชั้นที่หนึ่ง: test พังเกือบ 60% ในบรรดาโจทย์ที่โมเดล "ยังแก้ไม่ได้" เกือบ 60% มีปัญหาอยู่ที่ test เอง แบ่งเป็น 35.5% ที่ test แคบเกินไป (โมเดลแก้ถูกแล้วแต่ถูกตัดเพราะวิธีไม่ตรงกับที่คนเขียน test คิด) และ 18.8% ที่ test กว้างเกินไป (ตรวจสิ่งที่โจทย์ไม่เคยบอกให้ทำ) หนักสุดคือ OpenAI ถอด benchmark นี้ออกจากการใช้งานไปแล้วทั้งหมด ชั้นที่สอง: โมเดลจำเฉลยได้ งานวิจัยพบว่าโมเดล frontier สามารถขึ้นมาซ้ำเฉลยจา

submitted by /u/michaelhuman [link] [留言]

Lessons from building 24hours.lk and its companion mobile suite, the 24 Eco System Building an application is easy when everything is predictable. The database is clean. The API works. The user follows the expected flow. The server has enough resources. Nothing changes. Real enterprise applications are nothing like that. While working on 24hours.lk and the 24 Eco System mobile applications, I started to understand the difference between building something that works and building something that can survive in a real production environment. The most valuable part of the experience wasn't creating screens — it was dealing with everything that happens behind them. It Started Looking Like a Normal Application At first, an application can look deceptively simple: a user opens the app, authenticates, views some data, submits something. The backend processes the request. The database stores it. Done. But that simple flow hides a much larger engineering problem: What happens if two requests arrive at exactly the same time? What happens if the database becomes slow? What happens if the mobile app is running an older API version? What happens if a user closes the app halfway through an operation? What happens when thousands of records need to be retrieved? What happens when one service goes down but the rest of the ecosystem keeps running? That's where enterprise development really begins. 1. The Architecture Becomes More Important Than the Feature One of the biggest mindset changes I experienced was realizing that a feature is never really isolated. A new feature can touch mobile UI → API → authentication → business logic → database → storage → notifications → infrastructure, all at once — and changing one part can unexpectedly affect another. Because of that, I had to think about things like: Separation of concerns API contracts Service boundaries Database relationships Reusable business logic Error propagation Authentication flows Backward compatibility Deployment strategy

If you're using Claude to build websites or applications, one of the biggest improvements you can make is to stop treating Claude like a chatbot where you simply copy and paste code. Instead, you can set up a development workflow where Claude works on the project, GitHub stores the code, and Vercel handles deployment. The basic workflow looks like this: You → Claude → Code → GitHub → Vercel → Live Website Claude works on the project, GitHub keeps the source code and its history, and Vercel can automatically deploy new code pushed to the connected repository. Here's how I approach the setup. Start by discussing the project with Claude Don't immediately tell Claude: "Build me a website." First explain what you're actually trying to build. Tell Claude: What the product is Who the target users are What problem you're solving The main features How the business will operate What you already know What you don't know You can also give Claude examples of existing websites or products that are similar to what you're trying to build. The purpose of this stage isn't to generate code yet. It's to make sure Claude understands the project before development begins. Plan the technical side Once Claude understands the idea, decide how you're going to build it. This is where you determine things such as: Programming language Framework Database Authentication APIs Hosting Folder structure Major features Development priorities For example, you might choose JavaScript/TypeScript with Next.js, PHP with Laravel, or another stack depending on your project. The important thing is to make these decisions deliberately instead of letting the AI randomly choose technologies as the project develops. So my basic AI development process is: Discuss → Plan → Build → Test → Deploy → Improve Create a GitHub repository Next, create a repository for your project on GitHub. Think of GitHub as the central home for your project's source code and its change history. Once the repository exists, your developm

The Shift from Syntax to “Vibe Coding” Writing code used to be the bottleneck. Now, code is free and that’s precisely the problem. If you had told me Five years ago that my terminal would routinely spin up background execution agents, draft full-stack features, and push PRs before I finished my morning coffee, I would have assumed you were selling a tech startup pipe dream. Back then, GitHub Copilot was a neat trick: an glorified tab-completion tool that occasionally saved you from typing out a boiler-plate fetch request or regex string. Fast forward to today, and we’ve entered the era of “Vibe Coding.” You state intent in natural language. You direct agents in your editor. You prompt terminal workflows. Code manifests at conversational speed. You aren’t typing out syntax line-by-line; you’re steering an autonomous orchestra. The developer experience feels almost magical, fluid, and dizzyingly fast. But as the velocity of code creation hits lightspeed, an uncomfortable truth is beginning to surface across engineering teams: the cognitive load of software engineering hasn’t disappeared — it has simply shifted. We traded the friction of writing syntax for the far more taxing chore of evaluating architectural integrity, managing context drift, and catching silent edge-case failures in code we didn’t actually write. Code is easier to generate than ever, but system comprehension is at an all-time low. And nowhere is this trade-off creating more friction than in the middle tier of the software engineering workforce. The “Middle-Tier” Squeeze Senior engineers act as directors; AI handles the grunt work. Where does that leave everyone in between? For decades, the career progression of a software engineer followed a reliable, well-trodden path. You entered the industry as a junior, grinding away on bug fixes, writing unit tests, and building basic CRUD endpoints. Slowly, through hundreds of hours of raw syntax exposure, you built up mental models. You learned how state manag

submitted by /u/soap94 [link] [留言]

I was asked whether the system was sending patient data to an external body while the integration was half-built. I went and read the logs of every run. They all died early: some with a 415 because the content type wasn't what the other end expected, others with a 500. Not one showed an outbound call. I answered that nothing was going out. The first run that got past the 500 sent two requests carrying real clinical data . My answer had been false from the start, and the worst part is that it was false in a way that felt rigorous: I had looked. I had evidence. The evidence was logs of real executions, not assumptions. A negative says nothing on its own The mistake wasn't misreading the logs. It was not noticing what produced that silence. The runs died before reaching the code that sends. The log didn't say "I didn't send"; it said "I never got to the part that sends". Those are two different statements and they produce exactly the same output: nothing. That's the general shape of the problem, and it turns up everywhere once you look for it: A counter at zero can mean "it didn't happen" or "the counter was never incremented". A "not found" can mean "it doesn't exist" or "I looked in the wrong place". A green test can mean "it passed" or "it skipped itself". An exit 0 can mean "it worked" or "the command was strangled by a pipe that swallowed the exit code". A silent dashboard can mean "everything is fine" or "the process feeding it has been dead for three weeks". In all five, the evidence is identical. And in all five, the optimistic reading is the reassuring one, so it's the one chosen without thinking. The positive control The fix isn't to be more suspicious. It's to demand one specific thing before accepting any negative: Find something the log MUST show if the path was actually taken. If the system had reached the part that sends, something would have to appear in the log: the "preparing request" line, the batch identifier, the connection attempt. Any signal that

Als Hobbyprojekt submitted by /u/Puzzleheaded-Half993 [link] [留言]