Jose Canciani ᯅ

I took some @Waymos during my AZ visit. Mini review (2026): - Never felt in danger (about an hour total). - Couldn’t pick the model, but tried the new Ojai: very nice. Luggage fit easily but slid around on the floor. - Jaguars accelerate hard. Caught me off guard; they launch from lights too aggressively for my taste. - First ride: stopped at hotel entrance with three cars blocking the roundabout. Hesitated ~20s, it called support, then reversed and exited the other side. Unclear what happens if a car is behind. Not the Waymo’s fault though, but you can’t instruct yourself. I would like the AI to have decided that on its own. - Scottsdale wait times: 10–15 min (consistent across three rides). - Cars clean, instructions clear. Odd that they won’t stop on the roadside (local rules?). They enter parking lots (so longer walk times to pickup points), requiring complex maneuvers to exit. - Usually half the price of the cheapest Uber. Recommended.

Hello @airtminc, it's been over two months and support ticket 3465028 hasn't moved. My money is trapped in a Card I was informed would be cancelled if I kept using it. I have enough money in it not to fail. I need to use my money. I can’t recommend you again with this type of support :(

When development accelerates, feedback loops become more present, which is why everyone is so burnt out these days. A bigger upfront design means building more without proper validation, delegating to the AI what to build and how to resolve unknowns. This leads to building things nobody asked for, introducing accidental complexity that will bite you later.

This is the Will Smith spaghetti video of coding. debuild.co was ahead, could be the @Lovable or @v0 of today’s.

How (or better, when) to code review has been a hot topic for a while. I have some thoughts. This comes from direct experience: if you submit a “20,000-line PR” generated with AI and don’t find things it did wrong, I’d be worried. If you say you can, here’s a challenge: have your agent implement the Bluetooth 7 stack in the Linux kernel and submit it to see if it passes review. I agree we’ll read less and less. We’re adding SDLC steps to skip developer reviews for certain changes at work. But in a large codebase (millions of lines) and/or with clients on million-dollar annual contracts, break their processes twice in a row and your boss will make you read code or fire you. It always depends on how critical the code is and the change’s blast radius. Internal development tool? Vibecode it with few issues. Feature in integration APIs that could stop client billing? Read and understand it. Not every line in detail, but grasp the change and potential problems. Without knowing the code, evaluating risk is hard, and fixing later without new issues is harder. Will we get there? Maybe. A new project with the right guardrails can be vibe-coded and stay functional. - Without breaking stuff midway? Haven’t seen it yet. - More changes than a human with fewer errors? Yes, AI catches what devs forget. But with good coverage, clear module ownership, and reviews, errors were caught anyway. AI lets you iterate faster. Tips to help us: - Add AI to assist you in the review process. - Automate adversarial reviews. - Create artifacts to explain the changes that are easily digestible by us. - Success metric: you should be able to explain how things were implemented. You should feel you can still understand what’s happening in production. Use your judgment. It may be the only thing left for us in a few years 😅

Devs (?) blaming #PHP for security issues? This will happen with all languages. Some even confuse a language with a framework, thinking that since #IA needs no frameworks, they'll be fine. Well, no. Until AI generates binary code directly or offers a real-time streamed app, this can happen with any language. Even then, it will have security bugs: and worse, you may not find them.

I like Matt’s approach. We've all seen the videos of AI agents writing massive blocks of code in one go, but what Matt did is turn the practices we were already doing at big software enterprises into something an agent can follow reliably. I think he came up with this because he was already doing all of these things manually every single time he coded, and just wanted to automate the process. And instead of throwing away all the knowledge we gathered these decades (something so common in the age of Agents) he is trying to make Agents follow these playbooks reliably. For example: - Upfront Design & Specs: Instead of letting an agent dive straight into coding and guessing the architecture, his setup forces a rigorous grilling and spec phase. It's much like the technical design reviews and RFCs we've always used to hash out edge cases and align on requirements before writing a single line of code. - Vertical Slicing: It avoids the classic trap of building horizontally (all databases first, then APIs, then UI). Instead, it forces small, end-to-end increments that map right back to how agile teams break down massive epics into independently shippable chunks. - Bounded Diffs & Review: It’s the exact same idea as keeping changes under a few hundred lines for a strict code review, or maintaining Amazon-style service boundaries where each increment has a clear contract and can roll out or roll back alone. At the end of the day, letting an AI build without guardrails is a liability (well, all software is, let’s say it’s a greater one): it will just turn your codebase into spaghetti in a few months. His skills try to reduce the variance when your “teammate” is an Agent, keeping it firmly anchored to the enterprise discipline we know works.

What took you so long 😂 Anyway, this is great!

I was revisiting this thread I wrote on DRY a while back. This time framing it differently. We are now in the age of AI Agents. Yet I believe the three failure modes still hold, especially the last one. DRY was never “never repeat a line of code”. It was about duplicating knowledge. Agents can scatter the same rule across files and helpers make things harder, not easier. The usual traps are still there: 🏗️ Over-engineering. Models are trained on public codebases, and a lot of that code loves complex abstractions and indirections. So agents often reproduce them, and the added complexity will lead to worse results and even slop. 🏃 Generality added “just in case,” which now also bloats what the agent has to keep in context. They love defensive programming, so much that they check the same assumptions multiple times in the same call stack. 🕵️ Context switching. Small single-use functions were already annoying for humans. For an agent they mean extra file reads, more tokens, and a higher chance it loses the thread or reimplements the rule somewhere else. I still read the production code my agents generate (shocking, I know!). Not every line, but enough to understand what it’s doing, why it’s doing something, and where. A bit of local duplication is often cheaper than a maze of helpers neither of us can follow without jumping around. Both for them due to added context and jumps, and for us trying to understand what they meant. Agents are good at writing code. Keeping the single source of truth coherent is still on us. We should still strive to have a single, unambiguous source of truth for every piece of knowledge in our systems.

Great new feature from AWS. Does it make sense to use this instead of Athena if we just want queries on the Lakehouse? I imagine using Postgres tables as cache/intermediate tables could be useful/faster than what we do today (loading data in our database first). I’m not sure if this Postgres access is useful without your data already in Postgres.

Developer writes a feature. You ask the developer to take a break. The developer goes to the toilet and his mind discovers a better way to code the feature. Makes zero sense. Zero. I guess because we don't really understand what happens in the mind.

Nice topic: “does code quality still matter”. IMO, It's a discussion that's already expired. Pick a linter, the most widely used one for that language in the industry, and run it as pre-commit / test. Done, let's not waste any more time on this :) In another era I'd argue with you more; now I just don't have the time: if C prefers the brace on the new line, fine. I have way too much code to review to be debating this now 😂

I like this definition of the different levels of programming with AI. In my experience, if you write good documentation during “level 2”, you end up in level 3. After a couple of months building a system and patiently directing agents, you get a set of context files that allow for most new features to be almost perfect from just a prompt. So I tend to agree with @levelsio that what you need is just a good agent. Of course, the “let them iterate autonomously” is out of this picture. I don't think I've reached that level 😂. Even if most of my new prompts are good, there are still moments when it diverts or does stupid things. Not sure I would want to expose my users to this yet.

Very few videos on typing, and here we can see why. Like on the iPad, the split keyboard looks ugly, not Apple Keynote material 😂 I could never get used to the iPad keyboard, so this is my number one complaint. Could it be enough not to buy one? Yes, you type a lot. xitter.twitterapi.xyz/josecanciani/status/20…

So good!

I wonder if the menu can be moved to the left. It would probably blur some of the transition magic, but lefties would prefer it on their big finger.