DEV Community: Trevor Borthwick

Approach: AI Assisted Development

Trevor Borthwick — Wed, 25 Feb 2026 15:34:35 +0000

Building a product or proof of concept with AI as your coding partner can dramatically accelerate development — but only if you approach it with the right habits. Here's how to get the most out of AI-assisted development without painting yourself into a corner.

Start with Clear Problem Framing, Not Code
Before you open a chat window and ask for code, spend time articulating the problem you're solving and who you're solving it for. AI is remarkably good at generating solutions, but it can't validate whether you're solving the right problem. Write a short brief — even a few sentences — covering the user need, the core workflow, and what "done" looks like. Feed that context to the AI and let it help you pressure-test assumptions before a single line of code is written.

Use AI for Divergent Thinking First
One of AI's underused strengths is rapid ideation. Before committing to an architecture, ask it to propose three or four fundamentally different approaches to your problem. You might ask for a comparison of a server-rendered app versus a single-page app versus a CLI tool for the same use case. This is where AI shines — it can sketch out trade-offs in minutes that might take you hours to research. Evaluate the options with your own judgment, then converge on an approach.

Be Specific With Context and Constraints
Vague prompts produce generic code. The more you tell the AI about your stack, your constraints, your target users, and your existing codebase, the more useful its output becomes. Instead of "build me a login page," try "generate a login page using React and Tailwind that supports email/password and Google OAuth, stores sessions in HTTP-only cookies, and follows our existing component patterns." Attach relevant files or describe them. Context is the single biggest lever you have over output quality.
Treat AI Output as a Draft, Not a Deliverable
AI-generated code is a starting point. It will often look correct, run on the first try, and still contain subtle issues — hardcoded values, missing edge cases, insecure defaults, or patterns that won't scale. Read every line. Understand what it does and why. Refactor what doesn't fit your standards. The goal is to accelerate your workflow, not to outsource your judgment.
Build Incrementally and Validate Often
Resist the temptation to generate an entire application in one shot. Instead, work in small, testable increments: get a data model right, then the API layer, then the UI. Run the code after each step. When something breaks, share the error with the AI along with the relevant context and iterate. This tight feedback loop produces far better results than a single massive prompt and prevents compounding errors that become difficult to untangle.
Keep Architecture Decisions in Your Hands
AI can suggest architectures, but it doesn't understand the full picture of your team's skills, your deployment environment, your compliance requirements, or your long-term roadmap. Use AI to inform these decisions, but own them yourself. Document your architectural choices and the reasoning behind them — this becomes especially important when the POC evolves into a real product.
Use AI to Write Tests and Documentation Too
Don't just use AI for production code. Ask it to generate unit tests, integration tests, and documentation alongside the features it builds. This catches bugs early, forces clearer thinking about expected behavior, and leaves you with a much stronger foundation if the proof of concept gets the green light to continue.
Know When to Stop Prompting and Start Coding!
Sometimes the fastest path forward is to write the code yourself. If you've spent several rounds going back and forth trying to get the AI to produce exactly what you want, it may be quicker to take what you have, open your editor, and finish it manually. AI is a tool, not a replacement for craft. The best results come from developers who fluidly move between generating, reviewing, editing, and writing on their own.

AI-assisted development is a genuine force multiplier for building products and proofs of concept. The teams getting the best results aren't the ones who prompt the hardest — they're the ones who think clearly about what they're building, stay hands-on with the output, and use AI to remove friction rather than replace understanding.

Exposing Legacy Applications

Trevor Borthwick — Tue, 24 Feb 2026 12:32:27 +0000

As agentic AI systems become the new interface layer for enterprise workflows, organizations face a pressing question: how do you make decades-old legacy applications accessible to intelligent agents that can reason, plan, and act autonomously? The applications themselves may be aging, but the business logic they contain is often irreplaceable. Here's a practical roadmap for bridging the gap.

Step 1: Inventory and Classify Your Legacy Capabilities

Before any integration work begins, you need a clear map of what your legacy systems actually do. Walk through each application and catalog its core features, business rules, data entities, and user workflows. Classify each capability by its complexity, frequency of use, and value to the business. This inventory becomes the foundation for deciding what to expose first and how.

Step 2: Create a Stable API Layer

Most legacy applications weren't built with external consumption in mind. They may rely on proprietary protocols, batch file processing, screen-based interactions, or tightly coupled databases. The first technical step is to wrap these capabilities in a modern API layer — typically REST or gRPC endpoints — that provides a clean, versioned contract. Tools like API gateways, middleware platforms, or even lightweight wrapper services can sit in front of your legacy systems without requiring you to rewrite them. The goal is to decouple the what (the business function) from the how (the legacy implementation).

Step 3: Define Semantic Descriptions for Each Capability

Agentic AI systems don't read API documentation the way a developer does. They rely on structured, machine-readable descriptions to understand what a tool does, what inputs it needs, and what outputs it returns. This is where standards like the Model Context Protocol (MCP), OpenAPI specifications, or custom tool-definition schemas come in. For each API endpoint, write a clear natural-language description of its purpose, annotate parameters with types and constraints, and document expected behaviors and error states. The richer and more precise these descriptions are, the better an AI agent can reason about when and how to use each capability.

Step 4: Implement Authentication, Authorization, and Safety Guardrails

Giving an autonomous agent access to production systems demands careful attention to security. Establish scoped API keys or OAuth flows so agents operate with the minimum permissions necessary. Build in rate limiting, audit logging, and approval workflows for sensitive operations. Consider a "human-in-the-loop" confirmation step for any action that is destructive, irreversible, or financially significant. The principle is simple: agents should be empowered to act, but within well-defined boundaries.

Step 5: Handle Data Translation and Context Enrichment

Legacy systems often speak in codes, abbreviations, and internal identifiers that mean nothing to an AI agent or the end user it's serving. Add a translation layer that converts internal representations into meaningful, context-rich information. A customer status code of "A3" should surface as "Active — Enterprise Tier." Date formats, currency representations, and enumerated values should all be normalized. This makes the data not just accessible, but useful to an agent composing multi-step workflows.

Step 6: Enable Composability Through Orchestration

The real power of agentic AI emerges when an agent can chain multiple capabilities together to accomplish a goal. Design your exposed services to be composable — small, single-purpose operations that an agent can sequence as needed. Avoid building monolithic "mega-endpoints" that try to handle entire workflows. Instead, let the agent be the orchestrator. If your legacy system handles order creation, inventory checks, and shipment scheduling, expose each as a distinct tool and let the agent figure out the right sequence based on the user's intent.

Step 7: Test, Monitor, and Iterate

Once your legacy features are exposed, the work isn't over. Run AI agents against your APIs in sandbox environments to identify edge cases, ambiguous descriptions, and failure modes. Monitor real-world agent interactions to see which tools are being used, which are being misused, and which are being ignored entirely. Use these insights to refine your semantic descriptions, adjust guardrails, and prioritize the next set of capabilities to expose.

The Bigger Picture

Exposing legacy applications to agentic AI isn't about replacing those systems — it's about unlocking the value trapped inside them. By creating clean interfaces, rich descriptions, and thoughtful guardrails, you give AI agents the ability to leverage decades of business logic while keeping your proven systems intact. The organizations that do this well won't just modernize their technology stack; they'll fundamentally change how work gets done.

Building Software Solutions ... the next gen

Trevor Borthwick — Sun, 22 Feb 2026 23:32:31 +0000

Technology has always evolved rapidly, but the pace of change today is unprecedented. Cloud computing, artificial intelligence, automation, and distributed architectures are reshaping how organizations operate and compete. Building software solutions for tomorrow requires more than adopting new tools — it demands a fundamental shift in mindset, architecture, and leadership.

Designing for Change, Not Stability

Traditional software systems were designed for predictable environments and long release cycles. Tomorrow’s systems must be built for constant change. Business requirements shift quickly, markets evolve overnight, and customer expectations continue to rise.

Modern software architecture should emphasize:

Modularity and microservices to enable independent evolution of components
API-first design to promote interoperability and integration
Cloud-native principles for elasticity and resilience
Infrastructure as Code (IaC) to ensure repeatability and automation

The goal is not simply to build applications, but to build adaptable platforms that can respond to new opportunities and disruptions.

Cloud as the Foundation

Cloud computing is no longer just a hosting alternative — it is the foundation of digital innovation. Elastic scalability, global reach, managed services, and consumption-based pricing allow organizations to experiment, iterate, and grow without heavy capital investment.

Forward-looking software solutions leverage:

Managed databases and serverless architectures
Containerization and orchestration platforms
Continuous integration and deployment pipelines
Observability and automated monitoring

The cloud reduces operational friction and allows development teams to focus on delivering business value rather than maintaining infrastructure.

Intelligence by Design

Artificial intelligence is becoming embedded in modern software ecosystems. Tomorrow’s solutions will not simply automate tasks — they will learn, predict, and optimize.

Organizations should design systems that:

Capture and structure high-quality data
Enable real-time analytics and feedback loops
Integrate machine learning services where appropriate
Maintain transparency and governance around AI usage

AI should not be an afterthought layered onto existing systems. Instead, intelligent capabilities must be integrated into architectural decisions from the outset.

Security and Trust as Core Principles

As systems grow more distributed and data-driven, security becomes foundational. Tomorrow’s software must be secure by design, not secured after deployment.

Key considerations include:

Zero-trust architectures
Identity and access management at scale
Encryption in transit and at rest
Continuous vulnerability scanning and automated remediation

Beyond technical controls, organizations must prioritize ethical responsibility and regulatory compliance. Trust is a competitive advantage in the digital economy.

Building High-Performing Teams

Technology alone does not create transformative solutions — people do. Building software for tomorrow requires cross-functional collaboration, continuous learning, and a culture that embraces innovation.

Successful organizations:

Empower autonomous teams with clear accountability
Invest in upskilling and emerging technologies
Encourage experimentation and iterative development
Align technology strategy with business vision

Leadership must bridge the gap between strategy and execution, ensuring that emerging technologies translate into measurable outcomes.

Sustainability and Long-Term Thinking

Sustainable software development also means considering long-term operational efficiency and environmental impact. Efficient architectures, optimized workloads, and thoughtful cloud consumption reduce both costs and carbon footprint.

Tomorrow’s systems should be designed with lifecycle management in mind — scalable today, maintainable tomorrow, and adaptable for future innovations.

Conclusion

Building software solutions for tomorrow is not about chasing trends. It is about creating resilient, intelligent, and secure platforms that enable continuous evolution. Organizations that embrace cloud-native architectures, embed intelligence into their systems, prioritize security, and cultivate strong technical leadership will be best positioned to thrive in an increasingly digital world.

The future belongs to those who build with foresight — designing not just for current requirements, but for the possibilities that lie ahead.

Role of developers today...

Trevor Borthwick — Sun, 22 Feb 2026 23:25:57 +0000

Five years ago, if you asked someone what a software developer does, the answer was straightforward: they write code. They take requirements, turn them into logic, and ship features. The better you were at writing code, the better developer you were.
That definition is dissolving.
Not because developers are going away — they're not. But because the shape of the role is changing in ways that most people in the industry are still catching up to. And if you're a developer who hasn't felt the ground shift beneath you yet, you will soon.
The code is no longer the hard part
Let's start with the obvious. AI can write code now. Not perfectly, not independently, but well enough that the raw act of translating logic into syntax is no longer the bottleneck it used to be. Tools like Copilot, Cursor, and Claude are doing in seconds what used to take an afternoon.
This doesn't make developers irrelevant. It makes a certain type of developer irrelevant — the one whose entire value was knowing syntax and cranking out boilerplate. If your job could be replaced by a well-crafted prompt, that's not AI's fault. That's the job telling you it was always more mechanical than creative.
What AI can't do — at least not yet — is understand the why behind the code. Why this architecture over that one. Why this tradeoff matters for a team of four but not a team of forty. Why the elegant solution on paper becomes a maintenance nightmare in production. That kind of judgment is becoming the developer's primary currency.
From builder to orchestrator
Here's where it gets interesting. The modern developer is becoming less of a bricklayer and more of an architect — not in the old "software architect" sense of drawing diagrams nobody reads, but in the sense of orchestrating systems, tools, and even AI agents to produce outcomes.
You're not just writing a service anymore. You're choosing between building it, buying it, or prompting it into existence. You're stitching together APIs, managed services, AI capabilities, and legacy systems into something that works. The skill isn't in any single piece — it's in knowing how they all fit together and making decisions under uncertainty.
This is a fundamentally different skill set. It rewards breadth over depth in many contexts. It rewards systems thinking. It rewards the ability to hold complexity in your head without drowning in it.
Full-stack is the new baseline
There was a time when "full-stack developer" was a distinct role — someone who could work across the frontend and backend. Now it's closer to a baseline expectation, and the stack itself has expanded.
Today's developer is expected to have opinions on infrastructure, deployment pipelines, observability, security, and data — not just the application layer. Cloud platforms, containerization, CI/CD, and infrastructure-as-code have become part of the everyday vocabulary. You don't need to be an expert in all of it, but you can't be ignorant of any of it.
AI is accelerating this. When you can generate a working Terraform config or a Dockerfile by describing what you need, the barrier to entry across the stack drops. But the barrier to doing it well — understanding what you just generated, knowing when it's wrong, knowing how it interacts with everything else — that remains high. And that's where value lives now.
The rise of the soft skills developer
This might be the least discussed and most important shift. As the technical floor rises — as AI makes it easier for everyone to produce working code — the differentiator increasingly becomes everything around the code.
Communication. The ability to translate between business language and technical reality. Knowing how to push back on a bad requirement without burning a relationship. Writing documentation that people actually read. Mentoring junior developers. Navigating ambiguity when the product manager doesn't have all the answers (they never do).
For years the industry tolerated brilliant developers who couldn't collaborate. That era is ending. Not because companies got more enlightened, but because the economics changed. If AI can cover some of the raw technical output, the developer who can also align a team, clarify a problem, and ship the right thing — not just a thing — becomes dramatically more valuable.
So what does the new developer look like?
If I had to sketch the profile, it would be something like this:
They write less code than they used to, but they're responsible for more. They're comfortable delegating to AI tools without blindly trusting them. They think in systems, not just features. They can zoom out to architecture and zoom in to debug a race condition in the same afternoon. They communicate clearly — with machines and with people. They're perpetual learners, not because it sounds good on a résumé, but because the tools change every six months and standing still means falling behind.
They're not a 10x developer in the old sense of writing ten times more code. They're 10x in the sense of making better decisions, faster, with more leverage.
The uncomfortable part
Not every developer will thrive in this transition. If you've spent a career building deep expertise in a narrow technical lane and haven't invested in breadth, adaptability, or communication — this shift feels threatening. And it should feel uncomfortable, because comfort was never supposed to be the point.
But here's the thing: the developers who are willing to evolve have more leverage than ever before. You can build things now that would have taken a team of ten five years ago. You can prototype in hours, ship in days, and iterate in real time. The ceiling has never been higher for someone who knows how to use these tools and still thinks critically about what they're building.
The shape of the developer is changing. The question is whether you're changing with it.