Diego Fiori’s Post

In the domain of software development, this whole “AI has moved the bottleneck“ narrative is absolute untrue rubbish. But here is an actual shift the AI has caused… You’ve all seen me yammering on about small batch sizes and small batch processing and the fact that organizational agility and lean ways of working are impossible without small batch processing. When people used to type code with their fingertips on a keyboard, small batch processing was quite literally about when to know to stop typing and start integrating. But now, with coding agents generating the code, the only way to constrain the batch size is to constrain the prompt being fed into the agent. This is a new skill that developers are learning (although folks who became very adept at writing and discussing user stories effectively, have a nice headstart). I am seeing firsthand developers creating PR‘s anywhere from 1000 lines of code to 3000 lines of code, in very rapid succession. Clearly they’re still figuring out how to constrain their inputs into the agent to get those PR sizes down. It will be interesting to see how this plays out. I know the whiplash acceleration report has stats on the number of PR‘s being created since the advent of AI, but I would also love to see the stats on the size of the PR’s being created since the advent of AI. Remember, just because AI can write a lot of code very quickly, doesn’t necessarily make it a good idea.

AI code editors are making developers faster. But I think the bigger change is happening somewhere else. They are changing what we spend our time thinking about. I’ve been using Kiro personally, and one thing I’ve noticed is that I’m spending less time on: → Writing repetitive code → Searching for syntax → Creating boilerplate → Making small implementation changes And more time on: → What should I actually build? → Is this the right architecture? → Does this code make sense? → What could break? → How do I verify what the AI generated? That last part is important. AI can generate code quickly. But generating code and engineering software are not the same thing. The productivity gain isn't simply: “AI writes code → developer writes less code.” It’s closer to: “AI handles more of the mechanical work → developer can spend more attention on decisions, context, and verification.” And I think that’s going to become an increasingly important skill for software engineers. The question may not be: “How fast can you write code?” It may become: “How well can you guide, review, and reason about code that AI helps you create?” I’m still experimenting with this myself, but Kiro has already changed how I approach some parts of development. Curious to hear from other developers: Has AI coding changed what you spend most of your time doing?

An AI coding agent can write code that passes every test you gave it. And still build the wrong thing. Imagine you ask an agent: "Add password reset." It creates the endpoint. Generates the token. Sends the email. Adds tests. Everything passes. Then someone discovers that the reset token can be reused. The code is technically correct according to the tests. The implementation is clean. CI is green. But the requirement was never just: "Make password reset work." It was: "Make password reset work safely." That's a much harder thing to encode. This is where I think AI-assisted development is exposing an old engineering problem: We are very good at testing whether code does what we specified. We are much worse at specifying everything the system is supposed to mean. As agents get better at implementation, that gap becomes more important. The bottleneck isn't always: "Can the agent write the code?" Sometimes it's: "Did we give the agent enough information to know what correct actually means?" That changes the role of tests too. Tests aren't just a safety net for generated code. They are becoming part of the language through which we communicate intent to engineering agents. The better we can express intent as constraints, invariants and executable checks... …the more useful autonomous engineering becomes. Maybe the next generation of software engineering won't be about writing code faster. It will be about making correctness easier to define.

AI can understand your code. But understanding your entire codebase is a different problem. I've been experimenting with AI-assisted development, and this is one area where I've become more cautious. Give an AI coding agent a well-defined task, and it can often produce a working implementation surprisingly quickly. The challenge starts when the task depends on context that isn't obvious from the file you're editing. For example: • Why was this particular approach used? • Which other modules depend on this behaviour? • Is this logic handling an important business rule somewhere else? • What happens to existing integrations? • Is there a reason this seemingly "cleaner" implementation wasn't used before? These things aren't always obvious from the code sitting in front of you. A change can look perfectly reasonable in isolation and still introduce an unexpected problem somewhere else. That's why I think working with AI on an existing codebase requires more than just writing a good prompt. It requires understanding the system yourself. The better you understand the architecture, business logic and existing behaviour, the better you can guide the AI - and, more importantly, review what it produces. For me, AI is becoming a very useful development assistant. But the engineer still needs to be the one who understands the bigger picture. What has been your experience with AI coding agents when working with large or unfamiliar codebases?

One of the biggest changes in how I build software did not come from learning another framework. It came from changing how I work. I have always enjoyed taking an idea and figuring out how to turn it into something people can actually use. But there is a very different experience when you can sit down with an idea and go from “what if I built this?” to a working product much faster. That is what AI has changed for me. I use it to think through architecture, explore different approaches, write and refactor code, troubleshoot stubborn bugs and move quickly through implementation. But I have also learned not to be impressed simply because AI produced code that works. I have had to question its decisions, catch bad assumptions, rewrite parts of the implementation and sometimes throw an entire approach away because it was not the right solution. That process has made me a better developer. I am not using AI because I do not know how to build. I use it because I know what I am trying to build, why I am building it, and what good implementation should look like. For me, AI assisted development is not about replacing the developer. It is about giving an experienced developer more room to think, experiment and ship. And honestly, there is something incredibly exciting about having an idea in your head and knowing you have the tools and technical ability to bring it to life.

The problem with vibe coding is not the vibe. It’s the absence of a spec. AI coding tools have made software development ridiculously fast. You describe a feature, generate code, run it, fix what breaks, and keep moving. That is powerful. But without a clear spec, you are not really accelerating engineering. You are accelerating uncertainty. That is why I think the better model is Spec-Driven Vibe Coding. The idea is simple: Vibe Coding Prompt → Generate → Run → Fix → Repeat Spec-Driven Vibe Coding Intent → Specification → AI Implementation → Verification The difference is not whether AI writes the code. It can still write most of it. The difference is whether you have defined: What problem are we solving? What should the system do? What are the constraints? What should the architecture look like? What are the failure scenarios? What are the acceptance criteria? How will we verify the output? As AI gets better at implementation, this becomes even more important. Because a vague requirement + a fast coding agent does not give you good software. It gives you the wrong software faster. I think the developer’s role is shifting. Less time manually writing every line. More time defining the system, setting constraints, reviewing trade-offs, and verifying whether the output is actually good. That is the version of vibe coding I believe in. Move fast. Use AI heavily. But start with a spec.

Why Vibe Coding is Basically Playing with the Timebomb? Vibe coding is shipping code you don't understand. It feels like productivity. It's a timebomb. The pattern is everywhere now: prompt, copy, paste, ship. Ticket closed. Feature done. And for the happy path, it works. Then it detonates, in one of three places: 1. Debugging. Something breaks in production and you're staring at logic you accepted but never internalized. You can't ask the AI why its own code failed. That takes a human who understands it. 2. Security. AI doesn't know your threat model or your business context. Subtle flaws (bad input validation, injection risks, unsafe deserialization) look perfectly functional until they aren't. Auditing generated code needs more expertise, not less. 3. Scale. An endpoint that works for 10 users falls over at 10,000 if nobody thought about the performance characteristics of what got generated. Guessing is not engineering. Underneath all three is the same problem: you no longer own the code in your head. You've become a code babysitter. This isn't anti-AI. I use these tools every day. The difference is how: → As a learning accelerator: generate it, then dissect every line and ask why → With a validation harness: my own tests and checks wrapped around the AI's output → With a human in the loop, always: AI automates tasks, it can't automate judgment Co-pilot, not pilot. The engineer is still responsible for what ships. How are you keeping ownership of code that AI helps you write? Genuinely curious what's working for other teams. (Full write-up with an FAQ on AI and code quality is on my site, link in the comments.)

𝗔𝗜 𝗜𝘀𝗻'𝘁 𝗖𝗵𝗮𝗻𝗴𝗶𝗻𝗴 𝗦𝗼𝗳𝘁𝘄𝗮𝗿𝗲 𝗘𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴. 𝗜𝘁'𝘀 𝗖𝗵𝗮𝗹𝗹𝗲𝗻𝗴𝗶𝗻𝗴 𝗜𝘁. The conversation around AI in software development is moving backward. We see people talking about guardrails for AI agents. We see people building complex workflows to give models better context. These things have value. But we are rediscovering old principles and calling them new. We use to use compilers, type systems, linters, and tests to set limits. Now, we call these things AI guardrails. It is the same goal. The core problem is this: AI is probabilistic. It guesses the next word based on math. It can give you different answers for the same input. Software engineering must be deterministic. If you add 2 + 2, you must get 4 every single time. When code generation becomes probabilistic, our verification must become more deterministic. You cannot rely on a prompt to ensure quality. A better prompt only increases the chance of a good result. It does not guarantee it. Instead of playing with prompts, use this framework: • Generate: Let the AI write code, refactor, or explore ideas. Accept that it might be wrong. • Restrict: Force the code to follow rules. Use the compiler, type systems, and linters. These do not negotiate. They simply enforce rules. • Verify: Run unit tests, integration tests, and UI tests. Do not ask if the code looks correct. Ask if it passes the checks. • Decide: Use CI pipelines and quality gates. Only move code forward if it meets your strict standards. The AI changes who writes the code. It changes how fast we work. It does not change the engineering required to ship safe software. Stop trying to make the model "understand" your instructions perfectly. Instead, build a system that rejects the code when it fails. If you spend less time writing every line of code, spend that saved time building better tests, better contracts, and better pipelines. The more uncertain the generation becomes, the more certain your verification must be. Source: https://lnkd.in/grRjZsyp Optional learning community: https://t.me/GyaanSetuAi

After a long break during the summer holidays, I’m back here. ☀️ Even though I was less active on LinkedIn, I was still learning, experimenting, and working on specific projects that I hope to share and demo in the future. Recently, I’ve been exploring how to build software with AI without losing control of the process. This led me to Spec-Driven Development (SDD) — a way of working where specifications help guide the development process and AI agents. I found this very interesting, especially because it connects with ideas I have learned and used before in software development and process improvement. I wrote a new article about SDD, AI Agents, and the problems with “vibe coding”. 👉 Read the full article: https://lnkd.in/d_G2UJdk Are we learning to build software in a completely different way? #AI #AIAgents #SpecDrivenDevelopment #SoftwareEngineering #ContinuousImprovement

10 Things That Make Codex 10X More Useful. AI coding agents can do much more than generate code. But getting reliable results requires clear instructions, the right context, and a structured workflow. I recently recorded a video explaining 10 ways to make Codex more useful for real engineering work. Watch it here: https://lnkd.in/gP4bBAnm  Here is how I would approach it. → 1. Set clear master instructions Use AGENTS.md to define project rules, coding standards, and expectations. Give Codex a consistent foundation for its work. →  2. Choose the right reasoning level Use lighter reasoning for routine tasks and deeper reasoning for complex debugging, architecture, and problem-solving. →  3. Give complete task context Explain the goal, constraints, relevant files, inputs, and expected outcome. Better context reduces unnecessary iterations. →  4. Plan before writing code Use /plan to review the proposed approach, refine the steps, and confirm the direction before execution. →  5. Connect only essential plugins Start with the tools you actually need, such as Computer Use or Chrome. →  6. Let Codex work across tools Connect relevant development tools and supported applications so Codex can coordinate work across a broader workflow. →  7. Review code before committing Use /review to inspect changes, identify issues, and catch potential problems before they reach your repository. →  8. Turn repeated workflows into skills Store reusable instructions in SKILL.md files instead of rewriting the same prompts for every task. →  9. Organize work by project Give Codex access to the correct project folder, relevant files, and project-specific instructions. →  10. Manage outcomes, not every action Define the expected result, review the plan, monitor execution, and verify the final output. The important shift is moving from prompting Codex for individual coding tasks to giving it a structured engineering workflow. You still need to understand the system, review the changes, test the behavior, and verify that the result meets your requirements. Better AI coding starts with better engineering workflows. The tools will keep improving. The ability to define problems clearly, structure work, and evaluate results will remain valuable. ♻️ Repost if you found this helpful! 👉 Follow me, Jean Lee, for more AI Insights.